I bought a HomeWizard Wi-Fi P1 Meter to get a better view of my home's electricity and gas usage. With four solar panels on the roof, I also wanted to see how much electricity I was exporting to the grid. The HomeWizard app made that easy to monitor, but I wanted to do something with the data.
My home already uses HomeKit. Rather than simply watching surplus electricity flow back to the grid, I wanted to use it to trigger automations. Charging my electric bikes when there is power to spare seemed like a good place to start.
This article walks through the Homebridge plugin I built to bring the P1 Meter's readings into Apple Home. It covers the local API, the sensor workaround and the automations I use at home.
This is a personal project. I am not affiliated with HomeWizard, Apple or the other brands mentioned here.
Creating a custom HomeKit plugin
Homebridge
I wanted the meter's readings in Apple Home, so I built a plugin around HomeWizard's local API. Homebridge provides the bridge between that plugin and HomeKit. It is a Node.js platform that lets plugins expose devices and services to Apple Home.
Homebridge needs to keep running for the integration to remain available. A Raspberry Pi or another always-on computer is a practical choice. Follow the installation guide for your operating system rather than relying on a laptop that regularly goes to sleep.
Wi-Fi P1 API
The setup described here uses HomeWizard's local v1 API. Enable Local API for the meter in the HomeWizard app and make sure the computer running Homebridge can reach it on your network.
Compatibility note, September 2026: HomeWizard now recommends API v2 and plans to phase out v1. This article describes the original v1 integration; it is not a v2 setup guide. Check your device's support and the plugin's current compatibility before following these steps. HomeWizard's getting-started guide explains the API versions and their requirements.
For this plugin, I only need the recent measurement endpoint. A request to the meter looks like this:
GET http://192.168.1.50/api/v1/data
Replace 192.168.1.50 with your meter's local IP address. Here is an example response excerpt:
{
"smr_version": 50,
"meter_model": "ISKRA 2M550T-101",
"wifi_ssid": "My Wi-Fi",
"wifi_strength": 100,
"total_power_import_t1_kwh": 10830.511,
"total_power_import_t2_kwh": 2948.827,
"total_power_export_t1_kwh": 1285.951,
"total_power_export_t2_kwh": 2876.51,
"active_power_w": -678,
"active_power_l1_w": -676
}
The field I use is active_power_w. A positive value means the home is importing power from the grid; a negative value means it is exporting power. In this example, -678 means 678 watts are flowing back to the grid.
This is the net power measured at the grid connection, not the solar panels' total output or the home's total electricity demand. Some solar power may already be used inside the house before the remaining power reaches the grid. Watts describe the current power; the cumulative import and export readings use kilowatt-hours.
Setting up the accessories
I wanted two readings in Apple Home: power imported from the grid and power exported to it. Keeping them separate makes each one easier to use in an automation.
For this integration, I used HomeKit light sensors as a workaround. The plugin represents the readings as lux values, even though the underlying measurements are in watts. For example, a reading of 2,000 lux represents 2,000 watts in this setup. It is not a measurement of light.
That compromise is worth understanding before installing the plugin. Apple Home displays a light sensor and uses light-level terminology, but the value lets me trigger actions based on the meter's power readings. The export sensor shows surplus power sent to the grid, not everything the solar panels generate.
Heartbeat
In my setup, the plugin polls the meter every five seconds. Both accessories receive the result of that single request, rather than each accessory calling the API separately.
I used a TypeScript interface to give the accessories a shared beat method. After each poll, the plugin passes the new data to the accessories through that method. The interface defines the contract; the polling code controls when it runs. TypeScript itself does not schedule requests or reduce their number.
This keeps the data retrieval in one place. If I add another accessory later, it can use the same measurement without adding another request to the meter. Polling more frequently does not necessarily produce a newer reading: that also depends on how often the smart meter updates its data.
Using the plugin
Installation and setup
The plugin is called Homebridge Homewizard Power Consumption. Its source code and installation instructions are available in the GitHub repository.
- Install Homebridge using the official installation guide.
- Enable the meter's local v1 API and find its IP address. A DHCP reservation in your router helps keep that address stable.
- Install
homebridge-homewizard-power-consumptionthrough the Homebridge UI. If you manage plugins manually, use the installation method appropriate to your Homebridge setup. - Add the platform configuration below to the
platformsarray in Homebridge'sconfig.json, or enter the equivalent settings through the UI. Replace the example IP address with your meter's address. - Save the settings, restart Homebridge and check its logs for connection errors. If you have not already paired Homebridge with Apple Home, complete that step too.
{
"platform": "HomewizardPowerConsumption",
"ip": "192.168.1.50",
"pollInterval": 5,
"hidePowerConsumptionDevice": false,
"hidePowerReturnDevice": false
}
This is one platform entry, not a replacement for your entire Homebridge configuration. The five-second interval matches the setup described in this article; it is an explicit setting, not a claim about the plugin's default. Both sensors are enabled here. Set the relevant hide... option to true if you want to hide one.
Adding automations to my smart home
Because the plugin exposes imported and exported power as separate accessories, I can use them independently. In Apple Home, I create a sensor automation that reacts when the reported light level rises above or falls below a chosen threshold. The interface calls the value lux; in this plugin, I interpret that number as watts.
In my setup, exporting more than 600 watts triggers charging for my electric bikes. A separate automation stops charging if power imported from the grid exceeds 10,000 watts. These are the thresholds I chose for my own setup, not recommended values for every home.
The distinction matters: the second rule is a high-import stop condition. It does not stop charging as soon as the solar surplus disappears. If your goal is to charge only while surplus power is available, you need a separate stop rule for that behaviour. Leave a sensible gap between start and stop conditions so changing readings do not continually switch the charger on and off.

Conclusion
The P1 Meter gave me the readings; Homebridge made them useful in Apple Home. With one local API request feeding two accessories, I could turn imported and exported power into automation triggers.
The light-sensor representation is a workaround, and the setup depends on the API version supported by the meter and plugin. Even with those limitations, it gave me a practical way to use the data in my existing smart home. For me, that is the satisfying part of a project like this: taking a number I could already see and making it do something useful.
