I am not sure whether I read the behavior properly but I tried the default ‘thermostat’ and the custom ‘simple_thermostat’, both shows the same behavior.
I can send commands to NETATMO Thermostat (in my case valves) using buttons (or through scripts or services) that are accepted immediately but the button in the lovelace does not change, even after refreshing or waiting some time, the lovelace cards do not read the state of the netatmo valves. Both of them.
Unfortunately there are currently unresolved issues that cause the webhook for cloud linked instances to be banned most of the time. I’m working on that. Until then you either have to be patient as it only updates every 10-20 minutes or switch to using your own dev account in configuration.yaml. But for using webhook you have to expose your instance correctly.
I can either wait or learn something by trying the workaround. Would you be so kind and point me to a direction how to configure it in yaml? Or give me a link where I can learn the other approach than cloud? Thanks
Do you mean by “exposing my instance via port 443” that I need to open a port 443 in my router NAT and forward it to the IP address of my RPI? I did this. I also tried DMZ to be sure I am not misconfiguring it. I reinstalled netatmo integration and configure it through configuration.yaml where I added the ID and SECRET generated from NETATMO dev app. And it still not working.
And btw, I created a sensor from the current temperature in the netatmo valve entity. It has 0,5°C preciseness instead of 0,1°C in the netatmo app. Is this caused by the netatmo API, integration in HA or some settings I can polish? Thanks!
Yes, make your instance available to the WAN via 443.
Do you get any messages in the log?
As far as I’m aware, the valves report temperature in 0.5°C in increments and the thermostats in 0.1°C. Haven’t seen anything else neither via the API nor the Netatmo web interface.
I also tried the cloud nabu casa, still no success, so its probably not in a connection/port forwarding. The configuration of webhooks in netatmo configuration page also mentions that I need to add my external access address to configuration.yaml. I guess I don’t with nabu casa.
I don’t see any logs. The behavior is similar to the API connection.
Logs:
2020-12-03 10:01:06 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for circadian_lighting which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
2020-12-03 10:01:06 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
However, I have some configuration of logs in configuration.yaml which should be more detailed but I have never needed them. If you point me where to get them, I can provide you with more details.
I added external configuration url from the nabu casa interface for remote connection. However, remote access page shows in the first sentence that I do not need to configure anything when using nabu casa. If that is not true, let’s polish the documentation.
So it’s working. It is not fast as expected but it is working.
After couple of hours, since our morning discussion, the lovelace started to show error in controlling the API. I removed the integration before but I did not remove the entities. I restarted HA but something had to remain. So right now, I removed the integration and the entities. Restarted HA and added the netatmo integration again with configuration.yaml connection instead of API, which uses the ID and secret generated by netatmo dev apps interface.
Buttons away and frostguard works in 1-2 seconds. Heat does not work, not even the heat/schedule operation mode or boost button (it sends the command, the target temperature increases but the icon does not change, still schedule is lighten up). The same behavior I have with custom thermostat and the HA integrated thermostat (the icon of flame does not light up).
This seems to me to be a bug. Should I report it? I see that you are a developer of the netatmo integration, so I am asking whether it is enough here or whether you like to have an open issue on github. Thanks!
I have the same issue. Valve cards in HA does not work for setting the temperature or showing correct state of the settings.
I also have a NetAtmo weather station. Will switching to the “developer mode” conflict with my weather station setup through Integrations?
Not exactly sure what you mean by “switching to developer mode” but if you are referring to using your own developer account at dev.netatmo.com in configuration.yaml, then, no. Not at all. It might reset names should you have changed them manually in HA. But beyond this using that way is currently the recommended way to make use of webhook events from Netatmo. We are discussing solutions with Netatmo to get this fully supported in the future for the HA Cloud Link.
That is exactly what I mean
Now… However I have deleted my current NetAtmo integration. Then added the 3 lines to configuration.yaml, restarted HA and added the integration as described in the docs. Also on my NetAtmo dev-page, my Webhooks was banned so I unlocked it.
After the integration config has completed, I search for my “new” sensors. All names has changed and some of the old ones are not visible (like radio signal strenght etc.).
But still… I’m not able to use the climate card as seen in your video example above. It does not react instantly nor has it the turn-on/-off button…
Some sensors have been disabled by default but can be activated from the integrations menu.
If you thermostat does not respond instantly the webhook is likely not registered correctly. Check the logs for this message: INFO (MainThread) [homeassistant.components.netatmo.data_handler] Netatmo webhook successfully registered
As long as you don’t see that you’re missing a piece. Your instance has to be exposed and reachable via 443 (or 9443 but not tested yet). And if you’re behind a reverse proxy, that has to be configured correctly too.
