get_automation_runs
ChatGPTThe Netzero app's Automation > Past Runs for the last 14 days (the most recent kept), newest first. runs: each automation run with run_at (UTC), rule_id, the event that triggered it, the actions applied, success, and the error in plain English when it failed; retries of the same failure are collapsed and unmet AND conditions left out, as in the app. iog_runs: Intelligent Octopus Go dispatch starts and ends and what Netzero changed for them. grid_export_runs: Powerwall grid export sessions. Use it to answer why an automation did or did not run.
get_automations
ChatGPTThe site's automations as the Netzero app's Automation > Schedule lists them, in its order: rules, plus descriptions (rule id to the trigger and actions in plain English), currency for price triggers, and sun_times, today's sunrise and sunset. rule_type: time_of_day rules run at time, either HH:MM local time or sunrise_offset_N / sunset_offset_N (N minutes from sunrise or sunset), on iso_weekdays (1 = Monday to 7 = Sunday; null means every day) and, when set, only from date_from to date_to (MM-DD, wrapping the year when date_from is later). event_* rules run when their event condition becomes true: battery charge, solar, home, grid or battery power crossing a threshold, import or export price, grid status, tomorrow weather or solar estimate, daily grid import, temperature, Storm Watch, or EV charging starting or stopping; event_vpp rules no longer run, as Tesla removed VPP event data. Rules with the same and_group run only when all their conditions hold. actions keys: backup_reserve_percent, operational_mode (self_consumption = Self-Powered, autonomous = Time-Based Control), energy_exports (pv_only, battery_ok, never), grid_charging, storm_watch, off_grid_status, ev_charging, grid_export, hvac; no_action rules only notify. paused rules do not run; muted rules run without notifying; one_time rules pause after running; run_during_storm_watch_event rules also run while Storm Watch is active.
get_energy_history
ChatGPTThe Netzero app's Dashboard charts for a site: Tesla's telemetry_history (kind=graph, in English) for a day, month, billing month, year or lifetime, with electric vehicle charging split out of the home load, plus the grid cost the app shows. telemetry_history.graph_views has one view per flow (Home, Powerwall, Solar, Grid, and Vehicle for Tesla Wall Connector charging): main_value and secondary_main_value are the period totals in Wh (Powerwall: discharged and charged; Grid: imported and exported), and sections break them down by source and destination; raw_value is the number, value/after_adornment are display text, and a missing raw_value means 0. main_graph.graph holds the series in a compact form: series has the value titles, timestamps the UTC point times, and values one row per timestamp in series order, missing values as 0. For a day, values are 5-minute average power in W, labeled by the end of their interval (15 minutes for solar-only sites); for longer periods they are energy in Wh per day or month, and a month still running is padded with zeros to its end. For a day, the Powerwall view also has a 15-minute graph in sections with two untitled series, the backup reserve and the charge, in %. In the Home view, Charged is the EV charging energy and raw_value_orig, per timestamp, the Used value before it was taken out (null where nothing was). grid_cost is import_cost, export_cost, standing_charge and net_cost in the plan currency, priced at the rates of each 5- or 30-minute slot; it is a reconstruction at those rates, not the utility bill, and is null when the period cannot be priced (lifetime, or a tariff_details.cost_available of false). Totals do not show when the energy flowed: an estimate that depends on the time of day over a month or a season (another rate plan, a different schedule or export setting, more storage) needs get_energy_intervals for those months rather than a few sample days. Each day is its own call, and at most 20 tool calls are allowed per minute: a month or year has the daily or monthly totals in one call, and when the series of many days are needed, request them at that pace rather than all at once.
get_energy_intervals
ChatGPTOne calendar month of energy flows for a site in 30-minute intervals, as CSV: when the energy behind the totals of get_energy_history flowed. It is the data for any figure that depends on the time of day: the cost under another rate plan, the value of changing a schedule, the energy exports or the backup reserve, what more storage would save, or when the home draws from the grid. One row per interval: time is the start of the interval in the site time zone, with its UTC offset, and every other column is the energy in Wh that went from a source to a destination: solar_to_home, solar_to_powerwall, solar_to_grid, powerwall_to_home, powerwall_to_grid, grid_to_home and grid_to_powerwall. Totals are sums of columns: solar generated is the solar_to_ columns, home use the _to_home columns (electric vehicle charging included), grid import the grid_to_ columns, grid export the _to_grid columns, Powerwall discharge the powerwall_to_ columns and Powerwall charge the _to_powerwall columns. A solar-only site without an energy meter measures its generation alone: all of it is in solar_to_home and the grid columns are 0, so they say nothing about home use or the grid. The month of the installation starts at the installation, and the current month ends with the interval in progress, which is still filling. month must not be before the month of the site's installation_date (from list_energy_sites) or after the current month in the site time zone: such a month is an error. A full month is about 60,000 characters: get_energy_history has the daily and monthly totals of a whole year in one call, and the months an estimate rests on are the ones to request here.
get_ev_chargers
ChatGPTEV chargers at a site, as the Netzero app's Devices screen shows them. wall_connector_info: Tesla Wall Connectors by DIN with firmware version, part and serial number. live_status.wall_connectors: their live state, at most 10 seconds old: wall_connector_state (0 booting, 1 charging, 2 not connected, 4 connected, 5 scheduled, 6 negotiating, 7 error, 8 charging finished, 9 waiting for the car, 10 charging reduced), wall_connector_power in W, vin of the plugged-in car, and wall_connector_fault_state. enode_assets: devices linked through Enode, each with asset_id, vendor, info (brand, model, year), capabilities, is_reachable (whether Enode reached the device on its last try), last_seen, and needs_action/interventions when the user has to fix the link; for chargers also charge_state (isCharging, isPluggedIn, chargeRate in kW, maxCurrent in A) and Charge on Solar settings. ocpp_charge_point: a charger connected over OCPP, with status (the last StatusNotification), last_heartbeat_at, vendor, model, configuration and boot_notification.
get_ev_charging_history
ChatGPTEnergy charged into EVs at a site, in kWh per hour (up to 31 days) or per day (up to 400 days): per vehicle or charger, and the site total with overlapping reports from a car and its charger counted once. Ranges of up to 31 days also list charging sessions. Tesla charging is recorded only while the car charges at home. Costs are not included; get_energy_history prices the whole grid import.
get_hvac_devices
ChatGPTHeat pumps, air conditioners and thermostats at a site, as the Netzero app's Heating and Cooling screen shows them. enode_assets: devices linked through Enode, each with asset_id, vendor, info (brand, model, year), capabilities, is_reachable (whether Enode reached the device on its last try), last_seen, and needs_action/interventions when the user has to fix the link; for HVAC devices also thermostat_state (mode, holdType, heatSetpoint and coolSetpoint in degrees Celsius) and temperature_state (currentTemperature, isActive).
get_site_alerts
ChatGPTThe alerts Netzero raised for a site, newest first, as the Netzero app lists them under Devices > Alerts: alert_type, triggered_at (UTC) and alert_data with the details. alert_type: 1 no solar production, 2 a solar string not producing, 3 idle Powerwall, 4 degraded Powerwall, 5 grid outage, 6 grid restored, 7 firmware update, 8 Powerwall calibration, 9 Powerwall discharge cycle, 10 hardware alerts the system reported (alert_data.alerts, by code). system_alert_docs gives the title and description of each hardware alert code. Types 6, 7 and 8 are informational: a calibration is a routine Tesla maintenance cycle in which the Powerwall may discharge below the backup reserve and recharge, and needs no action. Type 9 is a controlled discharge requested by Tesla, for example on a recalled Powerwall 2. An alert is raised once per occurrence, so an old one may be resolved: get_site_status and get_site_diagnostics show the current state. An empty list means Netzero found nothing wrong: the raw component codes in get_site_diagnostics are not further alerts. Reference: https://docs.netzero.energy/docs/alerting/Alerting
get_site_diagnostics
ChatGPTThe Netzero app's Powerwall diagnostics (Devices > Gateway, Powerwall and Solar) from the latest stored snapshot, taken up to four times a day; recorded_at is when. diagnostics holds the gateway's own reports: config (the installed configuration, meters, grid code; its backup_reserve_percent is on the gateway scale, app % = (gateway % - 5) / 0.95), system_info, components and device (per-component state: gateway, Powerwalls, solar inverters and strings, with alerts), network (Ethernet, Wi-Fi and cellular links) and energy_signals (temperatures and lifetime charge and discharge). Use it to check that the system is configured and operating well. Alerts: diagnostic_alerts lists the hardware alerts that are actionable on their own, with titles and descriptions, as the app shows them under Devices > Alerts; an empty list means the system reports no problem. The alerts.active and activeAlerts lists inside diagnostics are the raw codes of each component. The system reports hundreds of them and most are informational states, routine self-tests, power-limiting states or normal operating conditions (for example the solar MCI codes of a Powerwall+ after sunset or on an unused input), which Netzero filters out. A raw code that is missing from diagnostic_alerts is not a fault, and its name is not a definition: Tesla does not publish any. https://www.netzero.energy/system_alerts describes every actionable code. Solar strings: voltage and current are one reading at recorded_at, so values near zero outside daylight are normal, and an input reported as not connected is normally an unused one. Netzero compares the strings over time and raises alert_type 2 in get_site_alerts when one stops producing. Capacity: powerwall_capacity is the weekly median full-pack energy in Wh per Powerwall serial number. It is not the usable energy, and a new Powerwall reports more than its 13.5 kWh rating. The reference is the medians in Netzero's Powerwall battery retention analysis, by age since manufacture. Powerwall 2: 14.1 kWh at 1-2 years, 13.8 at 2-4, 13.2 at 4-6 and 12.8 from 6 years on, where it stays flat. Powerwall 3: 14.4 kWh for the first 1.5 years, 14.25 at 1.5-2, 14.1 at 2-2.5 and 13.9 at 2.5-3. Loss follows cycling: Powerwall 2 units older than 3 years hold 14.0 kWh when discharging under 1 MWh a year and 12.8 kWh over 4 MWh a year (a full discharge every day is 5 MWh a year). About 4% of Powerwall 2 units older than 5 years are below 12 kWh. Tesla's warranty threshold is 70% of 13.5 kWh (9.45 kWh) at 10 years, and Netzero's degraded Powerwall alert uses the same 30% loss. Source: https://www.netzero.energy/content/2025-02/powerwall-analysis, https://www.netzero.energy/content/2025-10/powerwall-analysis-2, https://www.netzero.energy/content/2026-10/powerwall-analysis-3
get_site_status
ChatGPTTesla's site_info (the site's configuration) and live_status (live power flows) for a site, as the Netzero app gets them. site_info: backup_reserve_percent; default_real_mode is the operational mode (self_consumption = Self-Powered, autonomous = Time-Based Control); components.customer_preferred_export_rule is the energy exports setting (pv_only = solar only, battery_ok = everything, never); components.disallow_charge_from_grid_with_solar_installed true means grid charging is off; user_settings.storm_mode_enabled is Storm Watch; nameplate_energy is in Wh and nameplate_power in W. The rate plan is left out (see get_utility_rate_plan). live_status: power in W; battery_power is positive while discharging and negative while charging; grid_power is positive while importing and negative while exporting; percentage_charged is the Powerwall charge the app shows; powerwall_calibration and powerwall_discharge are set while Netzero sees a calibration or discharge cycle. live_status is at most 10 seconds old.
get_solar_estimates
ChatGPTModeled solar production for each date in a range (up to 31 days, from a year ago to tomorrow), as the Netzero app shows it on the day chart. Each date has hourly_w, the estimated AC power for each local hour in W (24 values, 23 or 25 on daylight saving days), and daily_wh, the day total in Wh, or an error. For today, daily_wh is the production so far plus the estimate for the remaining hours, which is lowered when production has fallen well short of the estimate. The model uses the panel arrays, historical or forecast weather, and a calibration against recent production (solar_adjustment_factors). panel_arrays is as configured in the app: capacity in kW DC, roof_pitch as rise per 12 run, azimuth in degrees (180 = south), dc_ac_ratio and losses in %.
get_utility_rate_plan
ChatGPTThe site's electricity rate plan in Tesla's tariff format (tariff_content_v2), as the Netzero app uses it for costs. seasons gives each season's date range (fromMonth/fromDay to toMonth/toDay) and time-of-use periods; each period lists windows from fromDayOfWeek to toDayOfWeek (0 = Monday, inclusive) and fromHour:fromMinute to toHour:toMinute in local time, a missing field being 0. energy_charges[season].rates[period] is the buy price per kWh in the plan currency, and sell_tariff has the same structure for exports. daily_charges, when present, are fixed charges per day. dynamic_rates_provider names the provider when Netzero keeps the plan updated with its prices (octopus_energy, tibber, amber_electric, entsoe, comed, ameren); the plan then holds only the latest prices. With a date, rates gives the price of every 5-minute slot of that local day as the app prices it (tariffs maps slot start to buy and sell rate and their periods; tariff_details has the current, minimum and maximum rates and whether costs are available).
get_vehicles
ChatGPTElectric vehicles at a site, as the Netzero app's Devices screen shows them. fleet_status.vehicles: Tesla vehicles with vin, display_name, key_paired, fleet_telemetry_config (synced, configured), site_id, and their last Fleet Telemetry state: charging_state, soc and charge_limit_soc in %, charge_rate_kw, charge_current_request_amps and charge_current_max_amps, ac_charging_energy_in_wh (this session), located_at_home, fast_charger_present, firmware_version, and telemetry_last_updated (Unix ms; the state is as of that time, not live). enode_assets: devices linked through Enode, each with asset_id, vendor, info (brand, model, year), capabilities, is_reachable (whether Enode reached the device on its last try), last_seen, and needs_action/interventions when the user has to fix the link; for vehicles also charge_state (batteryLevel, chargeLimit, isCharging, isPluggedIn, chargeRate in kW, range in km, batteryCapacity in kWh).
list_energy_sites
ChatGPTList the user's energy sites this connection can read (the Netzero app calls a site a system): site_id, name, time zone, city, installed components (solar arrays, Powerwalls, Wall Connectors), the rate plan and its dynamic price provider, and the billing day. Every other tool takes a site_id from this list.
set_ev_charging
ChatGPTStart or stop EV charging at a site, exactly as the EV charging action of a Netzero automation does. This acts on the user's vehicles and chargers, so it is for when the user asks for it. No device is named. start starts one vehicle or charger, the first that is plugged in and not charging: Tesla vehicles at home, then vehicles and chargers linked through Enode, then an OCPP charger, then Tesla Wall Connectors. stop stops every vehicle and charger that is charging. Returns ran, false when there was nothing to start or stop, and responses, the answer of each device a command went to: for a Tesla vehicle, result (true when the car took the command) and reason; for a Wall Connector, a message that holds an ErrorResponse when the command was refused; for an Enode device, the action with its state (PENDING, CONFIRMED, FAILED or CANCELLED) and failureReason; for an OCPP charger, success or error. A sleeping Tesla is woken first, so a call can take up to two minutes. At most 5 calls are allowed per minute, and Tesla vehicle commands also have a daily limit. On Netzero's demo account no command is sent: the call returns ran false with demo_account true.
set_site_configuration
ChatGPTChange a site's Powerwall configuration, as the Netzero app and its automations do: the backup reserve, the operational mode, energy exports, grid charging and Storm Watch. This changes how the home battery operates, so it is for when the user asks for a change. Give one or more values; one left out is not touched. preserve_charge sets the backup reserve to the Powerwall's current charge, which keeps it from discharging, for example while a vehicle charges. Tesla does not support a backup reserve of 81-99% and resets it to 80%. Returns previous_configuration, requested, and configuration as Tesla reports it after the change, with verified: true when the Powerwall system confirmed the change, false when it reports other values, so the change did not take effect, and null when it could not be checked, in which case compare configuration with requested. A site may not allow a value, for example grid charging or exports restricted by the utility, and it then stays as it was. A call takes up to about 20 seconds, and at most 5 are allowed per minute. On Netzero's demo account nothing is changed: the call answers as a change would, with demo_account true.
