search

alexf2015 / openhab-addons

Add-ons for openHAB 2.x
Eclipse Public License 2.0
7 stars 5 forks source link

Add smart home mode channel #5

Closed pacive closed 2 months ago

pacive commented 3 months ago

Needed to do a bit of refactoring to create a ResponseTransformer interface, since the data received from the API endpoint requires a different way of transforming it. Also, the API endpoint requires the systemId instead of the deviceId, so added that as a parameter on all genericDevice Things. It felt unnecessary to create a separate system Thing only for this channel. Not sure what the practical difference is between a system and a device, but if a system has several devices, the only downside with this solution as I can see is that the same channel will be present on all devices.

pacive commented 3 months ago

I also noticed that there seems to be a bug either in the API or in my heatpump's firmware. If I set the mode through the API, I can see on my heatpump that it gets set correctly, but the GET endpoint always returns { "smartHomeMode": "Default" }

alexf2015 commented 3 months ago

I am not sure if it is a good idea to simplify the model. The API is still in work. It could happen that NIBE adds more endpoints/Datapoints on system level. Currently my system (NIBE VVM320 + F2040 + ERS20-250) is handled as one device. This might change at least for newer models. This could result in confusion when people do not understand that they change parameters that have a system scope instead of a device scope.

I need to take a deeper look on your changes to decide.

pacive commented 3 months ago

If you think it would be better to have a separate Thing that wouldn't be a problem. Should it then reflect the hierarchy Nibe has (Account -> System -> Device), making it an intermediary bridge? Or should it be disconnected from the devices? Don't think any users will have that complex setups, but it would be hard to know which devices will be affected if someone would have a multi-system, multi-device setup.

alexf2015 commented 3 months ago

To my understanding a bridge is some device e.g. a physical gateway or a Cloud API that is used to access the "thing". Therefore a "nibe system" is just a "thing" like a "nibe device" although there is a logical hierarchy.

pacive commented 3 months ago

This could result in confusion when people do not understand that they change parameters that have a system scope instead of a device scope.

Wouldn't this still be the case then, since the actual settings will be applied on the devices?

But I can rework it to make it a separate thing, would probably not be that much of an effort.

alexf2015 commented 3 months ago

Maybe you are right. But one mor question: Auto-Discovery of channels on system level is not supported? You defined that "enum-type" channel in a static way.

pacive commented 3 months ago

Auto-Discovery of channels on system level is not supported?

Not as for the device parameters, there's a dedicated API-endpoint for smart home mode, and the enum values are only documented in the schema, not returned from the API itself. Not sure why Nibe decided that this setting needed special treatment, but it was the same in the old API, so perhaps it's some legacy thing.

alexf2015 commented 2 months ago

Thanks for your contribution.