Yeah, that’s what mine was copied from.
Save it in a file called iotawatt.yaml (or whatever else you want to call it) and save that file under config\packages. If you don’t already use packages, follow the link I left to get it set up. It’s a much nicer way to store your config.
I only have it set up for the CT’s but you can get everything as far as I know.
correct.
Update.
After a few days I thought I’d try again. Used the same IP address as before but this time it’s loaded successfully. I have zero idea why it worked this time.
So for now I’ll keep the REST API option in my back pocket. I may yet use it anyway.
Will be interested to see how stable this is.
Another question:
If I make changes to my IotaWatt set up, e.g. change my CT allocations, or rename things, create/edit/delete an Output, are these changes automatically reflected in the integration, or do I reload it?
Thanks
Can you give us a quick summary of where the issues with the integration are up to ?
I have followed this thread, and the one on the IOTAWATT support forums and am a little lost.
I have up until now done nearly all my IOTAWATT work in Node Red and am just now exploring the Integrations.
You rightly point out issues with the method of accumulation both here and on the IOTAWATT forums and seem to have done some work on customising the Custom Integration.
It does however now appear that this has been abandoned and the Integrated Integration is the one to use - the question therefore is did the changes you proposed get integrated into the mainsteam solution or are we now dealing with an inferior one ?
I have 3 phase incoming power (Australia) and 3 IOTAWATTS that between them monitor my main panel (where grid, consumption, battery and solar all terminate) and a sub panel where all my loads/circuits emanate from.
regards
Craig
Are you still using this method or did you settle on the Integration instead ? Have you noticed any wins if you did go for the Integration ?
Craig
I’m currently using the Integration. I haven’t had time to swap back and do any testing but I have a feeling that the update/refresh time was faster when I used the Rest sensors.
Yeah i use the REST/Query language extensively in Node Red and just wondering if i should just stick with that - will wait to see if Jean-Yves @jyavenard chimes in
Craig
I use the built-in integration and it feels all my requirements.
I know that there’s been PR about increasing how often HA should fetch.
The IoTaWatt doesn’t have a super fast CPU. When HA refreshes it queries all the sensors: input and output. For the energy sensors it calculates for everyone of them the data from midnight on that day.
By fetching too much you’re putting strain on the processor and it will lose accuracy and the author of IoTaWatt advised against it a few times.
If someone makes a PR that.makes the refresh interval configurable without changing the default I’ll be all for it.
OK good one thanks - i thought early in the piece you had modified the custom integration to make it more accurate - has now moved up to the standard integration ?
Craig
Yes, what used to be the custom integration moved into standard, with the exception of having unique id for the output sensors (because according to HA author, it doesn’t comply with his “rules” of what a unique id is.
What I had also added was the ability to have energy sensors that never rolled over: the one with _accumulated in the name. But obviously, someone didn’t see the advantages of it over the new iotawatt integration sensors.
So now instead of have energy sensors that are reset daily, which I find useless personally 
So I can no longer easily combine the energy sensors generated by the iotawatt integration (which reset daily) and the one from my Shellys energy meter, that never reset.
TBH, I started to get fed up with the current state of the iotawatt integration, it doesn’t do what I want anymore (I don’t want energy values that reset daily), and I wanted to be able to customise how each sensor could be presented.
Dealing with a custom_integration is painful as it breaks too easily and I didn’t want to maintain yet again another piece of software.
So I went back to the good old days of defining sensors, using REST and templates. This gives me energy sensors that only get reset on January 1st of each year (like it used to).
As I have defined a REST sensor as such:
sensor:
- platform: rest
name: IoTaWatt (Select)
resource: http://192.168.10.3/query?select=[Export.wh,Import.wh,Total.wh,Total_Solar.wh]&begin=y&end=m&group=all&header=yes
json_attributes:
- labels
- data
value_template: "on"
and:
template:
sensor:
- name: iotawatt
unique_id: iotawatt
state: >
{
{%- for i in range(0, state_attr('sensor.iotawatt_select', 'labels')|length|default(0)) -%}
"{{ state_attr('sensor.iotawatt_select', 'labels')[i] }}": {{ state_attr('sensor.iotawatt_select', 'data')[0][i] }}{% if not loop.last %}, {% endif %}
{%- endfor -%}
}
- name: iotawatt_export_kwh
unique_id: iotawatt_export_kwh
device_class: energy
unit_of_measurement: kWh
state_class: total_increasing
state: >
{{ (states("sensor.iotawatt")|from_json).Export|float / 1000 }}
- name: iotawatt_import_kwh
unique_id: iotawatt_import_kwh
device_class: energy
unit_of_measurement: kWh
state_class: total_increasing
state: >
{{ (states("sensor.iotawatt")|from_json).Import|float / 1000 }}
- name: iotawatt_total_kwh
unique_id: iotawatt_total_kwh
device_class: energy
unit_of_measurement: kWh
state_class: total_increasing
state: >
{{ (states("sensor.iotawatt")|from_json).Total|float / 1000 }}
- name: iotawatt_solar_kwh
unique_id: iotawatt_solar_kwh
device_class: energy
unit_of_measurement: kWh
state_class: total_increasing
state: >
{{ (states("sensor.iotawatt")|from_json).Total_Solar|float / 1000 }}
the creates like sensor.iotawatt_import_kwh with all the attributes you need to be used in the energy screen, and I can display as a card all that I used so far.
they get refresh every 30s, but the REST sensor can let you change how often you are fetching. With the query above, there’s no point querying it more than every minute.
If you want from the last 2y of data, the query is something like:
http://192.168.10.3/query?select=[Export.wh,Import.wh,Total.wh,Total_Solar.wh]&begin=y-1y&end=m&group=all&header=yes
If you want from a particular date, constant
http://192.168.10.3/query?select=[Export.wh,Import.wh,Total.wh,Total_Solar.wh]&begin=2023-01-01&end=m&group=all&header=yes
192.168.10.3 is to replace by the IP address of your iotawatt
This allows me to calculate the energy usage of a particular subcircuit. I have a sensor from the iota for a 3-phases subboard. One of the circuit on this sub-board is using a Shelly 3EM, so to exclude the energy as measured by the shelly I can do something like:
- name: Sub1 kWh
unique_id: sub1_adjusted_kwh
unit_of_measurement: kWh
device_class: energy
state_class: total_increasing
state: >
{% set adjustment = 0 %}
{{ states('sensor.iotawatt_sub1_kwh')|float - states('sensor.shelly3em_poolheatpump_channel_a_energy')|float - adjustment }}
It wouldn’t be doable with sensor that resets daily (I’m still puzzled on why someone ever thought it would be a good idea to submit that change)
Maybe this will help some.
Looks like they’re closing up shop:
That’s a shame. Now we must hope our units don’t die…
yeah, that’s a pity.
TBH, I’m fairly certain that some decisions on how the iotawatt integration had to work with HA (like not being able to assign a unique id etc), must have had a toll on the author. Couldn’t have been fun having to argue all the time that HA’s requirements made no sense for Iotawatt
looking at the schematic and the components used, couldn’t ESPHome be used and move the logging to HA? really its just CT’s and low voltage AC connected to MCP3208 adc’s. only thing i couldn’t figure out was power factor calculations using current esphome libraries
i bought my IoTaWatt a couple of years ago, but the quote to install was more than the device itself… so its sitting on a box under my desk still.
Hi @jyavenard ,
I can relate to your frustrations on the official Iotawatt integration for HA.
I always thought that you were a maintainer of that integration, and that you could decide to change/improve the integration. But that will have been my wrong interpretation.
Therefore I’d like to understand who or what is blocking the further improvement of the official integration. Could you clarify?
Thanks a lot.
From a Belgian Iotawatt fan
I would say that the Iotawatt firmware is doing higher resolution logging of energy data, and there is the principle of pushing data into databases (like influx) instead of pulling.
The timestamping is done in the Iotawatt, and data is stored/buffered in the device on SD card. So if wifi/internet connection was lost or the target database was down, the Iotawatt will restart upload of data from the last uploaded data point.
So quite some differences wrt ESPhome. I guess the unit could be run on ESPhome, but you would lose quite some features.
The creator of Iotawatt announced that production will stop, but support will continue.
He is also apparently working on an ESP32 version where all the design will be posted online so we could get them made elsewhere. Lets hope that does happen. I my opinion the iotawatt is the best solution on the market (I have all 14 channels used on mine) and so I now fear it failing and needing to be replaced without any available.
Take a look at the Vue 2. Using the Esphome firmware available you can create whatever you want and it’s totally local. Check it out.
5310
The 3 phase version is listed as ‘coming soon’, plus it’s crazy expensive compared to iotawatt.
Yeah i am a little terrified of this as well - i have 3 of the IOTAWATT - one of which is mission critical in that it controls/provides all the data from my mains, grid, solar and battery so i can make all my automation decisions. It does this in realtime and allows me to maintain manual charge and discharge of my inverters that control my batteries.
I think i am going to replace this critical one with 3 of the Eastron meters (and keep one spare) and will then have to write my own Modbus code to grab the data and store it away in influx and send to PVOutput etc
Craig