search

Nebula83 / openhab2-addons

Add-ons for openHAB 2.x
Eclipse Public License 1.0
8 stars 2 forks source link

Evohome #6

Closed foxy82 closed 7 years ago

foxy82 commented 7 years ago

It's starting to work with status updates!

Handler base class now we update state correctly for temperature. Set Temperature is being returned as 0.0 so need to find out why. Also we get NumberFormatException on some devices as the zoneId is coming out as 123.0 and the .0 bit is incorrect.

Nebula83 commented 7 years ago

Phat! It works! I get actual zone temps, super nice! I did have to throw away all my evohome related things for the discovery to work again but I think that is normal.

Nebula83 commented 7 years ago

By the way

Handler base class now we update state correctly for temperature. Set Temperature is being returned as 0.0 so need to find out why. Also we get NumberFormatException on some devices as the zoneId is coming out as 123.0 and the .0 bit is incorrect.

Yeah, that's not right. The ApiClient logs all responses on the debug trace. Could you maybe privately send me the JSON repsonse data for tese items?

I also found the issue with the zone target temp: in HeatSetpointStatus the @SerializedName("TargetTemperature") should be @SerializedName("targetTemperature"). If you change that it'll work =).

The double where an integer is expected has to do with the fact that sometimes in discoverHeatingZones in EvohomeDiscoveryService the properties serialize to doubles instead of integers/longs. One robust way to fix this is to replace a call like properties.put(EvohomeBindingConstants.LOCATION_ID, locationId); into properties.put(EvohomeBindingConstants.LOCATION_ID, String.format("%1$d", locationId));.

foxy82 commented 7 years ago

It is very strange - I can't see what is casting it. I was thinking we could change the zoneId, loactionId etc to Strings in the model - after all they don't need to have arithmetic done on them...

Nebula83 commented 7 years ago

Oh, yeah, might as well, smart =) Go ahead, no problems on my side. I think it has to do with the internals of openhab, a bug causing that conversion to bork?

2017-06-02 13:32 GMT+02:00 foxy82 notifications@github.com:

It is very strange - I can't see what is casting it. I was thinking we could change the zoneId, loactionId etc to Strings in the model - after all they don't need to have arithmetic done on them...

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Nebula83/openhab2-addons/pull/6#issuecomment-305761662, or mute the thread https://github.com/notifications/unsubscribe-auth/AL51rFPa-RERIwchXzEXse0CaNGyKonCks5r__K1gaJpZM4NrohY .

foxy82 commented 7 years ago

Yeah my json comes in as "12345". Gson makes it an int and I was adding it straight to the properties. Then somewhere along the way I retrieve it and I get "12345.0" - it would also only happen on some zones. Very odd. I can't believe there could be such a fundamental bug in openhab but I can't see how I can be doing it!