This is how I filter it out in the configuration.yaml
:
logger:
default: warning
logs:
homeassistant.components.iotawatt: fatal
This is how I filter it out in the configuration.yaml
:
logger:
default: warning
logs:
homeassistant.components.iotawatt: fatal
Any known issues with the Iotawatt integration and the new Beta that is currently available? 2022.3.Beta
Good evening all, i have iotawatt and have been useing your integration gregtd.
Is there any way to make it up date faster than 30 sec?
Thank you
The iotawatt maintainer has clearly stated his opinion on the matter on how that was a very bad idea due to the increased load on the punny processor found in the iotawatt.
The integration is querying it for a lot of data, rather often, even if every 30s it takes several seconds for the iotawatt to process each query during which it canât sample the inputs. This has an impact on the sampling rate at which the iotawatt can take its measurement. If you query too often, youâll get bad data.
I donât know if this was touched upon yet, but is there a way to enable the Hz
and powerfactor sensors?
Are we supposed to use the IoTaWatt support built into HA 2022.11.x etc, or should we still be adding in this repository and using the HACS / GitHub release ?
TIA
Ignore the repo. Use the built-in integration
I know that shortly after support was integrated into Home Assistant there was still a good reason to use the external integration. But I donât remember what that was and Iâm afraid to switch in fear of losing all my data.
The repo allowed to manually define a unique id which the official integration couldnât do (the main dev thinks that a unique id must be automatic. But for the iotawatt it makes little sense with outputs).
Problem is that since this custom integration was released it hasnât been maintained. So it probably wonât run with 2022.11 anymore
Bugger as being able to rename / give a âcleanâ unique ID, would be good. Be good just to be able to have outputs etc be able to be named to make sense in the Energy Dashboard / not have .wh on the end.
Whatâs the problem with using the MAC address as the unique id as many other integrations do?
Pretty easy to obtain the MAC address from http://<iotawatt IP/FQDN>/status?wifi=yes
The issue isnât about assigning a unique Id to the device, but to the output.
Input have a unique ID: the input number from 1 to 14.
But the output name can vary as you wish, and per HA design rules, you canât use that. So they make up a number. I think that requirement of them is silly and makes zero technical sense. Because the id may be unique but you can still change the formula on the iotawatt
Anyway, thereâs nothing we can do about it.
I should also remove all the_Wh entries, it pegs the device too much. Better to use the new iotawatt integrators
Can you link me to the design rules? Whatâs preventing things like MAC_output1 through to MAC_output14? or if you canât use words MAC:01 through MAC:14?
There is no output 1 or 14. They arenât numbered. Thatâs the whole issue.
Anyhow, Iâve argued this with the HA dev for many days and they always refused our changes. Not going to argue this any further.
If you think you know better, youâre more than welcome to submit a pull request and see how you go.
FWIW the last PR on this subject have been closed with ânot plannedâ
Last one was "outputs" from iotawatt appear twice in HA ¡ Issue #79355 ¡ home-assistant/core ¡ GitHub
Rest assured youâre not arguing with me.
Iâm just trying to understand the reasons for the existing resistance.
I use the custom integration and I canât objectively imagine how the official integration could be considered better.
Iâm surprised the custom integration would still be working with any recent HA. They have changed too many things upstream and Iâm not aware of recent updates in the custom one to maintain compatibility
I SEEM to be using it.
Custom integration is working fine here 2022.11.3