Tado binding stopped working after software update

ArturSnk · January 25, 2022, 11:29am

Hi, everyone!

After upgrade software on tado AC control, I lost control it from openHAB. By tado APP everything working. I can see the commands in openHAB which was sent by Tado App, but when I’m trying to send command by openHAB, looks like tado AC control ignore the command or not receiving, I see this in events.log:

2022-01-25 11:45:36.059 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'tado_hvac_mode' received command DRY
2022-01-25 11:45:36.060 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'tado_hvac_mode' predicted to become DRY
2022-01-25 11:45:36.061 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tado_hvac_mode' changed from OFF to DRY
2022-01-25 11:45:41.332 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tado_hvac_mode' changed from DRY to OFF
2022-01-25 11:45:42.145 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'tado_hvac_mode' received command FAN
2022-01-25 11:45:42.146 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'tado_hvac_mode' predicted to become FAN
2022-01-25 11:45:42.147 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tado_hvac_mode' changed from OFF to FAN
2022-01-25 11:45:47.406 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tado_hvac_mode' changed from FAN to OFF

And I don’t hear a peep sound from AC control, confirming that command received. One more interesting thing, that OFF command (if I turn it ON by Tado APP and OFF by OpenHab), Tado AC control receiving very well, only when I am trying to turn it ON (from OFF to HEAT, for example) it not receiving commands. Before upgrade everything worked fine. Unfortunately, Tado does not support the API. What could it be? Sorry for my english.

ArturSnk · January 25, 2022, 8:55pm

Just found in openhab.log:

2022-01-25 17:09:59.828 [WARN ] [ado.internal.handler.TadoZoneHandler] - Could not apply HVAC change on home 680446 and zone 1: Operation updateZoneOverlay failed with error 422
org.openhab.binding.tado.internal.api.ApiException: Operation updateZoneOverlay failed with error 422
	at org.openhab.binding.tado.internal.api.client.HomeApi.updateZoneOverlay(HomeApi.java:625) ~[?:?]
	at org.openhab.binding.tado.internal.handler.TadoZoneHandler.setOverlay(TadoZoneHandler.java:110) ~[?:?]
	at org.openhab.binding.tado.internal.TadoHvacChange.apply(TadoHvacChange.java:123) ~[?:?]
	at org.openhab.binding.tado.internal.handler.TadoZoneHandler.lambda$0(TadoZoneHandler.java:303) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Same api exception, always when I’m trying to send any command by openHAB, except command OFF to HVAC Mode - just this command working now.

ArturSnk · January 28, 2022, 8:48pm

Can me help somebody? Why it not working anymore? What can I do?

Freeride79 · May 9, 2022, 7:56pm

Hello, I also had the issue with the Tado AC Binding. It was not working anymore with Openhab. I found help on Github. There are a few guys working on this issue and I try to test the new binding. It would be great to have another person to test the new binding.

The latest version (jar file) is working again with my openhab. But some command seem to be tricky.

github.com/openhab/openhab-addons

[tado] Add null annotations and null checks to code

openhab:main ← andrewfg:tado-#12552

opened 04:30PM - 03 Apr 22 UTC

andrewfg

+458 -326

Fixes #12552 In PR #12470 the reviewer @jlaur remarked that the new code was… missing @NonNullByDefault tags, and therefore lacking the proper potential NPE validation checks. I added that this applies not only to the new code, but also to the whole binding. So for those reasons I opened issue #12552.. This PR resolves that issue as follows.. - Added @NonNullByDefault tags to all human created classes; (impossible on the Swagger generated classes). - On the majority of variables/fields thus asserted to be @NonNull -- deleted the redundant null checks. - On the few variables/fields that had to remain @Nullable -- added null checks and NPE avoidance code. - Added `final` on fields created in the constructor. - If the API returns a null state value, the respective channel (if any) is now updated with a `UndefType.UNDEF` state. - Added `default` throw code on `switch` statements that map API enum's to binding enum's (will cause exceptions in case the API enum's might be extended, but the binding enum's are not). - Eliminated all other remaining compiler warnings on the human created classes; (impossible on the Swagger generated classes). - Eliminated "Bridge not initialized" exception resp. log warning on shutdown. Note that the Tado REST API schema has many JSON fields where, (depending on the type of Tado device, and its respective state), the JSON elements may be either missing or null. So the Swagger generated API DTO classes must NOT have @NonNullByDefault. And therefore the 'trick' in this PR is to ensure that the data transfer between @Nullable API classes and @NonNullByDefault human created classes has not broken anything. => Further testing by a few Tado device owners is requested!

If you want to test the jar, select to uninstall the release version of the Tado binding in your OH Settings UI under Bindings. Then take the jar file from the zip from the github link, and drop it in the ‘add-ons’ folder on your OH system.