[netatmo] API changes and valve support

[navybk]

Since it is impossible to succeed when trying to add Netatmo vales into OpenHab - in german they are named Thermostat which is confusing - I was investigating how the code base for the binding could be improved to support these vales. Soon I discovered, the current lib is not only automatic created by swagger code generation, it also lacks some simple base functionality and does not completely encapsulate lib tasks:

The token handling does not support token refresh, the Binding has to deal with eventual Retrofit errors and the dependency libs are years old and, most important, the whole lib does not implement the current state of the API definition which will soon deprecate several old methods (https://dev.netatmo.com/resources/technical/reference/deprecated)

With all this points, it was a relatively fast decision to implement a complete new approach of the API without swagger. So I did in Kotlin and it's here: https://github.com/navybk/netatmo-java-api Even so there is this repo for then Netatmo Binding refactored to this new lib: https://github.com/navybk/openhab2-addons

Would it be possible to integrate this lib and the Refactoring into Openhab after testings and checks? Also I'd like to see some helping comments, since I am not sure, which functionality the valve Things should support.

Thanks in advance

Michael

[lolodomo]

@clinique : WDYT ? Is it a good idea to switch to a new API ?

@navybk : except the switch to the new API, are there a lot of changes in the binding ? Maybe you could already push a PR so that we can review your changes ? Put "[WIP]" in the title if you think you have not finished.

[clinique]

@navybk : Yes, many API entry point have been marked as obsolete. What does not please me is that all those entries disappearing tends to hide modules between a Netatmo logic layer (home, rooms in favour of thermostat module for example). So I suppose one day, we'll more or less lose access to a given module data / actions. So I'm really wondering about the future interest of Netatmo in my setup. But this is not for today.

@lolodomo : I think switching API can be onpenly considered. I've never found swagger generated classes state of the art in term of encapsulation and inheritance, leading to many code rewriting (and for example the usage of reflection in the binding).

[clinique]

@navybk : I second lolodomo regarding the interest of a PR in order to study the positive impact of the switch to Kotlin.

[navybk]

@lolodomo I made the interface changes as small as possible to provide a smooth migration between both libs but it definitly needs some life tests. The repo include unit tests which need some minor improvement, therefore I need some real life data.

@clinique I will make a PR which is really just for testing purposes. I do not own all devices so on certain points I was acting 'blind' and since the documentation from netatmo is not 100% correct corresponding to the actual data they send I hope for feedback from users. Even more it's also worth to think about a switch from a device/module centric approach to a room centric one. The lib could provide convenience methods for most of the needs, so the Binding do not have to deal with the nested data like it does at the moment

[navybk]

@clinique @lolodomo I just added an early PR to get in touch with the lib https://github.com/openhab/openhab2-addons/pull/3823 Most of the changes are just readability ones, since the lib is designed (from my perspective) for convenience. So the main functionalities are still working, but untested. The device discovery is working also for valves, but the valves itselfes needs improvent

[andre2308]

Hi, i have some radiatiorvalves from Netatmo and want to test the new Addon. Can you provide a kar file for the Addon?

[navybk]

Sincerely I have to admit, that I do not know how (and also why). But here is the jar which you could put into you openhab2 addon folder.

org.openhab.binding.netatmo-2.4.0-SNAPSHOT.zip

[andre2308]

Thank You. I will run it in debug with OH 2.3 and post The Logs. Hope I could help You.

[andre2308]

@navybk Hey, i have installed your jar file. After the Bridge Configuration had openHAB find my Setup (1 Relais and 5 Valves). The API, Relais and Valves are shown as Online in Things section.

The given Names have the Addon recognized right, the only Data i get was the Signal strenth from the Relais.

I Think the Locationchannel can you remove from OH.

In the OH logfile i get these lines again and again: `2018-08-27 17:22:56.020 [WARN ] [o.internal.channelhelper.RadioHelper] - The module has no method to access WifiStatus property

2018-08-27 17:22:56.023 [WARN ] [o.internal.channelhelper.RadioHelper] - The module has no method to access Location property`

In events.log goes this `2018-08-27 17:17:50.849 [.ItemChannelLinkAddedEvent] - Link 'netatmo_NRV_d076366e_090000007fd5_WifiStatus-netatmo:NRV:d076366e:090000007fd5:WifiStatus' has been added.

2018-08-27 17:17:50.879 [.ItemChannelLinkAddedEvent] - Link 'netatmo_NRV_d076366e_090000007fd5_Location-netatmo:NRV:d076366e:090000007fd5:Location' has been added.

2018-08-27 17:17:50.908 [me.event.InboxRemovedEvent] - Discovery Result with UID 'netatmo:NRV:d076366e:090000007fd5' has been removed.

2018-08-27 17:17:50.925 [hingStatusInfoChangedEvent] - 'netatmo:NRV:d076366e:090000007fd5' changed from UNINITIALIZED to INITIALIZING

2018-08-27 17:17:50.934 [hingStatusInfoChangedEvent] - 'netatmo:NRV:d076366e:090000007fd5' changed from INITIALIZING to OFFLINE: Pending parent object initialization

2018-08-27 17:17:50.947 [vent.ItemStateChangedEvent] - netatmo_NRV_d076366e_090000007fd5_WifiStatus changed from NULL to UNDEF

2018-08-27 17:17:50.977 [vent.ItemStateChangedEvent] - netatmo_NRV_d076366e_090000007fd5_Location changed from NULL to UNDEF`

Do you need a Debug log also?

Thanks for your work, i'am can't sill awaiting to controll my valves over OH..

[andre2308]

Hey, here is a Debug Log from the Binding. I added the Relais and One Valve of five.

Debug Netatmo.txt

[navybk]

Thanks. I pushed a new release where I added support for rooms. Valves are read only and therefore only for event channel usable. For rooms we can change temperature. The following updates will include the home thing to change a schedule and the ability to change temperatures in a room

[andre2308]

Thank you too, for the great work. I have tryed your new release and the Rooms are shown, but at time without values, the same at the valves.

Here is a log, hope i could help you. =)

Error's at Startup:

22:54:33.547 [DEBUG] [org.openhab.binding.netatmo ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=317, service.bundleid=179, service.scope=singleton} - org.openhab.binding.netatmo 22:54:33.595 [WARN ] [e.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE) 22:54:33.650 [ERROR] [etatmo.internal.NetatmoHandlerFactory] - Supports netatmo:NAPlug netatmo:NAPlug 22:54:33.651 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:netatmoapi:29f7f7ea' changed from UNINITIALIZED to INITIALIZING 22:54:33.652 [ERROR] [etatmo.internal.NetatmoHandlerFactory] - Supports netatmo:Room netatmo:Room 22:54:33.653 [ERROR] [etatmo.internal.NetatmoHandlerFactory] - Insatnciate netatmo:Room netatmo:Room 22:54:33.654 [ERROR] [etatmo.internal.NetatmoHandlerFactory] - Insatnciate netatmo:NAPlug netatmo:Room 22:54:33.657 [ERROR] [etatmo.internal.NetatmoHandlerFactory] - Supports netatmo:NRV netatmo:NRV 22:54:33.660 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:netatmoapi:29f7f7ea' changed from INITIALIZING to ONLINE 22:54:33.660 [ERROR] [etatmo.internal.NetatmoHandlerFactory] - Insatnciate netatmo:NRV netatmo:Room 22:54:33.674 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Initializing class org.openhab.binding.netatmo.internal.energy.RelayHandler with id '70:ee:50:0e:76:68' 22:54:33.731 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Scheduling update channel thread in 30 s 22:54:33.786 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:Room:29f7f7ea:4192506790' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING 22:54:33.793 [DEBUG] [o.handler.AbstractNetatmoThingHandler] - Refreshing netatmo:Room:29f7f7ea:4192506790:Temperature 22:54:33.801 [DEBUG] [o.handler.AbstractNetatmoThingHandler] - Refreshing netatmo:Room:29f7f7ea:4192506790:WindowOpen 22:54:33.802 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:NAPlug:29f7f7ea:70ee500e7668' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING 22:54:33.803 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:NRV:29f7f7ea:090000006f1e' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING 22:54:33.804 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:Room:29f7f7ea:4192506790' changed from INITIALIZING to OFFLINE: Pending parent object initialization 22:54:33.807 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:NAPlug:29f7f7ea:70ee500e7668' changed from INITIALIZING to OFFLINE: Pending parent object initialization 22:54:33.810 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:NRV:29f7f7ea:090000006f1e' changed from INITIALIZING to OFFLINE: Pending parent object initialization 22:54:33.812 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'netatmo:NAPlug:29f7f7ea:70ee500e7668' changed from OFFLINE: Pending parent object initialization to ONLINE 22:54:33.814 [DEBUG] [o.handler.AbstractNetatmoThingHandler] - Refreshing netatmo:NAPlug:29f7f7ea:70ee500e7668:WifiStatus 22:54:33.815 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Data aged of 3600 s 22:54:33.816 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Trying to update channels on device 70:ee:50:0e:76:68 22:54:33.816 [DEBUG] [.netatmo.internal.energy.RelayHandler] - start update readings with ID 70:ee:50:0e:76:68 and home: 5a0fe144ae476318478b6ad3 22:54:33.816 [DEBUG] [o.handler.AbstractNetatmoThingHandler] - Refreshing netatmo:NRV:29f7f7ea:090000006f1e:RfStatus 22:54:33.818 [DEBUG] [o.handler.AbstractNetatmoThingHandler] - Refreshing netatmo:NAPlug:29f7f7ea:70ee500e7668:Location 22:54:33.819 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Data aged of 3600 s 22:54:33.819 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Trying to update channels on device 70:ee:50:0e:76:68 22:54:33.820 [DEBUG] [.netatmo.internal.energy.RelayHandler] - start update readings with ID 70:ee:50:0e:76:68 and home: 5a0fe144ae476318478b6ad3 22:54:33.843 [DEBUG] [o.handler.AbstractNetatmoThingHandler] - Refreshing netatmo:NRV:29f7f7ea:090000006f1e:BatteryVP 22:54:33.869 [INFO ] [smarthome.event.ItemStateChangedEvent] - netatmo_Room_29f7f7ea_4192506790_Temperature changed from NULL to UNDEF 22:54:33.874 [INFO ] [smarthome.event.ItemStateChangedEvent] - netatmo_Room_29f7f7ea_4192506790_WindowOpen changed from NULL to UNDEF 22:54:33.875 [INFO ] [smarthome.event.ItemStateChangedEvent] - netatmo_NRV_29f7f7ea_090000006f1e_RfStatus changed from NULL to UNDEF 22:54:33.876 [INFO ] [smarthome.event.ItemStateChangedEvent] - netatmo_NRV_29f7f7ea_090000006f1e_BatteryVP changed from NULL to UNDEF

Normal Data Update

22:56:07.050 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Data aged of 24586019 s 22:56:07.052 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Trying to update channels on device 70:ee:50:0e:76:68 22:56:07.053 [DEBUG] [.netatmo.internal.energy.RelayHandler] - start update readings with ID 70:ee:50:0e:76:68 and home: 5a0fe144ae476318478b6ad3 22:56:07.766 [DEBUG] [.netatmo.internal.energy.RelayHandler] - module RelayModule(id=70:ee:50:0e:76:68, modulesBridged=[09:00:00:00:6e:fc, 09:00:00:00:6f:1e, 09:00:00:00:6f:be, 09:00:00:00:7f:d5, 09:00:00:00:8a:21], connectedToBoiler=false, moduleName=Heizköperthermostate, setupDate=2017-11-18T07:29:08, rfStrength=104, wifiStrength=45, type=RELAY) childs: 5 parentId: 5a0fe144ae476318478b6ad3 22:56:07.768 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Successfully updated device 70:ee:50:0e:76:68 readings! Now updating channels 22:56:07.770 [DEBUG] [scovery.NetatmoModuleDiscoveryService] - thingType NAPlug id: 70:ee:50:0e:76:68 uid: NHC 22:56:07.771 [DEBUG] [scovery.NetatmoModuleDiscoveryService] - thingType NAPlug id: 70:ee:50:0e:76:68 uid: NATherm1 22:56:07.772 [DEBUG] [scovery.NetatmoModuleDiscoveryService] - thingType NAPlug id: 70:ee:50:0e:76:68 uid: NACamera 22:56:07.772 [DEBUG] [scovery.NetatmoModuleDiscoveryService] - thingType NAPlug id: 70:ee:50:0e:76:68 uid: NAPlug 22:56:07.773 [DEBUG] [scovery.NetatmoModuleDiscoveryService] - set Equipment_ID: 70:ee:50:0e:76:68parentId: 5a0fe144ae476318478b6ad3 22:56:07.775 [DEBUG] [scovery.NetatmoModuleDiscoveryService] - Add module netatmo:NAPlug:29f7f7ea:70ee500e7668 label: Heizköperthermostate 22:56:07.776 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - The device has no method to access Location property 22:56:07.777 [INFO ] [smarthome.event.ItemStateChangedEvent] - netatmo_NAPlug_29f7f7ea_70ee500e7668_WifiStatus changed from 46 to 45 22:56:07.779 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Updating child modules of 70:ee:50:0e:76:68 22:56:07.780 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Updating child module 09:00:00:00:6f:1e 22:56:08.167 [WARN ] [.internal.channelhelper.BatteryHelper] - The module has no property: RfStatus 22:56:08.169 [WARN ] [mo.internal.channelhelper.RadioHelper] - The module has no method to access RfStatus property 22:56:08.648 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - cancel refresh job 22:56:08.650 [DEBUG] [.netatmo.handler.NetatmoDeviceHandler] - Scheduling update channel thread in 30 s

[bushvin]

This is awesome, @clinique and @navybk . I will be testing your new binding this week-end and provide feedback.

[clinique]

Thanks for your anthousiastic comment @bushvin , but @navybk deserves all congratulations. I did nothing on this.

[bushvin]

I just installed your jar, and everything was automagically detected. (yay!)

I can see my NetAtmo weather and temperature modules, my thermostat and relay, but I cannot see my valves and rooms.

I have discovered in the past there are 2 different products including valves, which are totally different. One set has a relay, a thermostat and a couple of valves (extendable): https://www.netatmo.com/product/energy/thermostat

The other is a relay and valves (without the thermostat): https://www.netatmo.com/en-US/product/energy/valves

Is it possible you have implemented the latter only?

when using the netatmo API samples (https://api.netatmo.com/api/homesdata), this is the info I get about my modules:

modules:

    id: "70:ee:50:0c:76:0e"
    type: "NAPlug"
    name: "Relay0"
    setup_date: 1511620715

    modules_bridged:
        "04:00:00:0c:49:70"
        "09:00:00:00:0e:48"
        "09:00:00:00:0e:97"
        "09:00:00:00:0e:b3"
        "09:00:00:00:0f:32"
        "09:00:00:00:0f:d1"
        "09:00:00:00:10:2d"

    id: "04:00:00:0c:49:70"
    type: "NATherm1"
    name: "Thermostat"
    setup_date: 1511620795
    room_id: "2658696900"
    bridge: "70:ee:50:0c:76:0e"

    id: "09:00:00:00:0e:48"
    type: "NRV"
    name: "Valve 0"
    setup_date: 1511706408
    room_id: "930212719"
    bridge: "70:ee:50:0c:76:0e"

    id: "09:00:00:00:0e:97"
    type: "NRV"
    name: "Valve 1"
    setup_date: 1512503991
    room_id: "2924468986"
    bridge: "70:ee:50:0c:76:0e"

    ...

When setting up things manually, I cannot find this "NRV" module.

Any thoughts?

[bushvin]

I did notice one thing: There's no where to specify (temperature) units to be used with your devices, causing the odd error in the log whenever an item needs conversion:

00:02:12.976 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '35.10413414058384518057209788821637630462646484375' of item netatmo_NAMain_aef6e57a_70ee501c66f4_HeatIndex with format '%.0f %unit%': Conversion = 'u' 00:02:12.983 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '32.28294171657594091584542184136807918548583984375' of item netatmo_NAModule4_aef6e57a_03000004dcb2_HeatIndex with format '%.0f %unit%': Conversion = 'u' 00:02:12.990 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '56.6445523496669096630284911952912807464599609375' of item netatmo_NAModule1_aef6e57a_0200001c76bc_HeatIndex with format '%.0f %unit%': Conversion = 'u'

It goes away if I specifically define a format with the item, as in "Sensor Heat Index [%.2f °C]"

[navybk]

I just installed your jar, and everything was automagically detected. (yay!)

I can see my NetAtmo weather and temperature modules, my thermostat and relay, but I cannot see my valves and rooms.

I have discovered in the past there are 2 different products including valves, which are totally different. One set has a relay, a thermostat and a couple of valves (extendable): https://www.netatmo.com/product/energy/thermostat

No I did not forget and they should be visible on the current build. Which repository did you use? The development is done here: https://github.com/navybk/openhab2-addons/tree/netatmo_refactoring

In upcomming releases the "relay" will dispappear due a lack of usable data and the thermostat and valves will only be readable.The lib should only support rooms so far for writing purposes. The api supports to change settings only on those and a single device could not be addressed directly.

I did notice one thing: There's no where to specify (temperature) units to be used with your devices, causing the odd error in the log whenever an item needs conversion:

The temperature is set fixed to SIUnits.CELSIUS (which makes sense to me – nobody sane really want's to use Fahrenheit ;) ) but it could be changed but then either the binding or openhab has to deal with a conversion. Speaking of your problem I have no idea, why this is happening. Maybe @lolodomo has a better insight of this

[bushvin]

Sincerely I have to admit, that I do not know how (and also why). But here is the jar which you could put into you openhab2 addon folder.

org.openhab.binding.netatmo-2.4.0-SNAPSHOT.zip

This is the snapshot I installed. If there's a different one, please, do tell.

[bushvin]

@navybk Can you tell me where I can download your latest build?

[navybk]

@navybk Can you tell me where I can download your latest build?

I just uploaded my latest build: https://github.com/navybk/openhab2-addons/releases/download/Beta4/org.openhab.binding.netatmo-2.4.0-SNAPSHOT.jar This is still WIP

[bushvin]

Hi @navybk Just downloaded and installed your update.

After configuring the Bridge, it detected my NetAtmo Weather products, but not my Energy products. I was able to manually add a Relay, but anything else I tried to add would be OFFLINE.

Here's the debug logs from installation of the binding until after the addition of the room.

openhab.log

[navybk]

Thanks for the log: here is an update https://github.com/navybk/openhab2-addons/releases/download/beta5/org.openhab.binding.netatmo-2.4.0-SNAPSHOT.jar

[bushvin]

Thanks for the update, @navybk ! Now all my devices got recognized.

My API, Home, thermostat relay/plug and valves are online, NAMain and NATherm1 are unitialized, Thermostat module, Outdoor module, additional module and Room modules, are offline. There doesn't seem to be much in the log, tho

openhab.log

[BPC83]

I read in some of the first posts, that valves are read only, will it ever be possible to set at target temperature form openhab..?

[ghost]

Hi

I have installed 2.4.0 too, but I have the same effect. Netatmo Bridge, Base Station and Rain Gauge are online. Other sensors are recognized as Item, but stay in state OFFLINE. In the openhab2 Logfile I see:

2018-11-21 23:16:50.845 [ERROR] [nternal.handler.NetatmoDeviceHandler] - Unable to connect Netatmo API : 500 Internal Server Error
2018-11-21 23:16:53.884 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
        at org.openhab.binding.netatmo.internal.station.NAModule3Handler.getNAThingProperty(NAModule3Handler.java:46) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.AbstractNetatmoThingHandler.lambda$3(AbstractNetatmoThingHandler.java:109) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) ~[?:?]
        at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:?]
        at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) ~[?:?]
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:?]
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:?]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
        at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.AbstractNetatmoThingHandler.updateChannels(AbstractNetatmoThingHandler.java:106) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoModuleHandler.updateChannels(NetatmoModuleHandler.java:97) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoDeviceHandler.lambda$7(NetatmoDeviceHandler.java:202) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:159) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoDeviceHandler.lambda$5(NetatmoDeviceHandler.java:200) ~[?:?]
        at java.util.concurrent.ConcurrentHashMap.forEach(ConcurrentHashMap.java:1597) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoDeviceHandler.updateChildModules(NetatmoDeviceHandler.java:198) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoDeviceHandler.updateChannels(NetatmoDeviceHandler.java:158) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:159) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoModuleHandler.requestParentRefresh(NetatmoModuleHandler.java:113) ~[?:?]
        at org.openhab.binding.netatmo.internal.handler.NetatmoModuleHandler.lambda$0(NetatmoModuleHandler.java:51) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

The Items stay in this state. How can I bring them online?

[notz]

I have tried your updated binding and it detects all my rooms and valves, but the valves never get any data and rooms never update the status.

I checked your code and i don't see any handling for updating rooms status at an fixed interval. I have implemented a dirty hack and now i get updated values, but the handling in your plugin is not ideal. Because every thing will query the hole home on update. So their are really much requests to the netatmo api if you have more rooms and valves.

I think it should be periodically updated 1x time by the bridge device and shared to all things (rooms, valves). Are you still working on that? I saw that you didn't have pushed your latest code to github. Changes to netatmo api 0.4.2 are still missing.

[navybk]

Was a bit busy the last days but will continue soon.

[ecki84]

i am only use the GUI, Paper UI and so on, how it is possible, to copy yor jar file on my openhab rasp?

Edit: have it installed, valves and rooms found, one time sync Temperatur, than nothing, cant Change any Temperatur

[mdillmann]

@navybk Did you had a chance to continue on the lib/binding during the last weeks ?

[mdillmann]

What do the current maintainers (@lolodomo and @clinique) think of the idea to split the binding into functional parts much like Netatmo has organized their web-apps ? (weather, energy and security)

The current binding could continue as it is for the time beeing, whereas the energy and security would be separate, installable bindings ? Mainly the current implementation is centered around the Module (and does the refresh on each of these individually) whereas the security and energy "things" center around the "room" as the top-level abstraction.

One could also think of NOT having a one-for-all Netatmo-API in Java, but having separate ones there as well. Reason behind this: weather-API is quite stable, but security and energy APIs will still evolve because of new products being introduced by Netatmo (eg. smoke-detector and video-doorbell announced for end of this year) Also people/developers normaly own only a subset of Netatmos products, so development/testing velocity could increase.

[lolodomo]

I am not against this idea even if it could introduce lots of confusion to the final user. How many new bindings do you imagine ? 3 ?

[bushvin]

I am not a maintainer of this project, but I am opposed.

All parts use the same API, which means each separate binding will need the same library to connect to the API. Such a thing is very hard to maintain. Splitting up the binding will not necessarily guarantee a stable code base on one of the binding. I am not a coder by conviction, but I do know a bit about software development.

Many of the issues faced on this DEVELOPMENT codebase are due to a complete rewrite of the code by @navybk (hat tip), and needs to be tested thoroughly before being production worthy.

Everybody contributing to this project does so on their own personal time, but sometimes life gets in the way. If you are unhappy with the (progress of the) development, you can always use the stable code and setup a separate instance to test the development code (like i do). Or you could just pitch in additional code to help the binding progress.

-- Sent from my awesome Motorola X4

On Wed, 6 Feb 2019, 19:48 lolodomo <notifications@github.com wrote:

I am not against this idea even if it could introduce lots of confusion to the final user. How many new bindings do you imagine ? 3 ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhab/openhab2-addons/issues/3806#issuecomment-461140432, or mute the thread https://github.com/notifications/unsubscribe-auth/AEkGYBvC1T6QwZwXGCoa5i3xBY2pz1llks5vKyN3gaJpZM4V1R8i .

-- Disclaimer http://www.critter.be/maildisclaimer

[mdillmann]

Looking at navybk's code he tried to replicate the behavior of the weather-api to the energy/security side to be "compatible" with the current binding (his Api be more or less a drop-in-replacement of the current lib). The strategies and abstractions in Netatmo's energy/security api's are totally different to the weather side. So I am proposing to keep the current Netatmo-binding as it is, with current lib based on Swagger. Then go a new route with a new (single ?) Netatmo-Api only for energy/security and two new separate bindings (energy and security), or even separate Api-libs. I think these will be probably easier to maintain compared to squeezing everything into the same API and a single binding because of the different pace Netatmo will enhance/change these APIs going forward

[clinique]

There are pros and cons. At one time, I had a load of work in order to have a unified approach of Netatmo API for the three perimeters, and I thought the same, splitting it would enable smoother and quicker evolutions, corrections of each part. On the other hand, when Netatmo updates his API, this increases the maintenance workload. But as I wrote somewhere earlier, I think the way Netatmo makes his API evolve currently tends to hide more and more modules and devices behind concepts (rooms, house). That is quite normal because their added value is here, but it makes it more difficult to link it with OH concepts - while in the same time they do not give enough grips on interesting things (notifications, webhooks...).

Reason why I took a bit of distance in the evolutions of this binding - Fortunately, there are not so much issues raised and it seems quite stable- letting other come with fresher ideas.

I like @navybk 's approach, because swagger maintenance is also quite tedious, and not as powerfull as I would expect (e.g. the absence of inheritance in the generated code).

Maybe a first step, that would not break anything and let things evolves would be to extract all the common API connection in a dedicated io service.

[col1958]

Hi all,

I own a set of Netatmo valves+relay. Home automation is based on a bticino myhome system. Alexa is present, also. My idea was to use openhab (on a raspberry) as the supervisor of the whole home automation system. Thanks to the OWN bticino binding I succeeded to integrate the bticino system in openhab. I used the openhab skill of Alexa to add voice control to OH. My Netatmo system is controlled via app and by Alexa (with netatmo energy skill).

I am trying to control netatmo valves via this binding but at this point I have online only the api and the relay in PaperUI. I had to use manual discovery, because the auto did not work. Valve Things are offline "Pending parent object initialization". How can I access the relay via browser to have all the information about module and device id? I have access to the mac addresses from the app, but nothing else. Is the device id of a valve the mac address of the relay?

Moreover, I would like to use openhab to control valves as in the app, programming the time schedule and the temperature of each valve and reading the temperature of each valve. How far are we from this?

It is a bit strange to be able to control each valve from app or from alexa and not be able to do it from openhab.

I am available for testing and for a little programming even though I am a newbie with openhab (but with some linux and java experience).

[col1958]

A small update. Now everything is online. I had to manually unlink and link a channel. But the valves can only be read ... and they only expose battery level and signal strength (both NaN). Home has appeared and rooms also. Inside the room thing there is what I was looking for. However they are not editable in paperUi: if you try to change anything (like the location), you receive this error:

2019-03-23 17:56:08.564 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.NullPointerException: null at org.openhab.binding.netatmo.internal.handler.AbstractNetatmoThingHandler.getParentId(AbstractNetatmoThingHandler.java:148) ~[?:?] at org.openhab.binding.netatmo.internal.handler.NetatmoRoomHandler.requestParentRefresh(NetatmoRoomHandler.java:213) ~[?:?] at org.openhab.binding.netatmo.internal.handler.NetatmoRoomHandler.lambda$0(NetatmoRoomHandler.java:60) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?] at java.lang.Thread.run(Thread.java:748) [?:?]

The problem seems to be in the device ID field of the room, which is set to the Home ID when you manually discover the thing, while paperUI expects a field in the form xx:xx:xx:xx:xx:xx.

Is it something that can be fixed?

[navybk]

Yes, and I think there are a lot of issues of the current binding, depending of this logic. But instead of fixing this, I was about to implement a new logic in a complete new binding. Since I stumbled across some Openhab design decisions and lacked time to check out all of my own, I am still looking for someone with more deep insights of the openhab framework.

My current approach was to align the netatmo binding to the actual api calls, get a rid of showing devices and show rooms for the energy line (security, weather and aircare are postponed by now, but are accessible within the lib).

So speaking how much work is needed: depends on how much help I would get ;)

Michael

PS: I would not use swagger, since – as already mentioned – it cannot map the inheritance of objects correctly

[col1958]

I am not sure I can be of much help with the "insights" of openhab, being relatively new to it (a few months). With respect to other bindings which are heavily maintained (say the bticino OpenWebNet binding I am using), this one was far behind, both for automatic discovery of things and for the easy implementation of netatmo valves and bridges, until i stumbled on @navybk rivisitation of the original binding. I am in favor of a new binding which should reproduce into openhab the same framework one faces inside the "netatmo energy" app. I would love to see the graphs of temperature in each room (sensor and setpoint) and to be able to configure each valve as I do in the app. The weekly and daily schedule of all the valves should be equally made available and editable by the user. Global temperature settings (Comfort, Comfort+, etc) each valve should be possible as well.

I do not know HOW to do it, but I can help to test and modify any piece of code someone else with much knowledge of the OH environment has written.

At the moment the main drawback in my opinion is that the interface towards paperUI has to be modified because things cannot be edited due to data mismatches in some fields. The second most important problem is refresh: data do not seem to be refreshed in control panel. Should they? Persistence?

[col1958]

@navybk: have you had time to work on this project? I think a new binding on the line of the netatmo energy app would be a great idea. I have a new relay+ smart valve system with no thermostat. Happy to help for what I can.

[jimmybaeyens]

Hi all, is anything actively done on this? I want to enroll this in openhab as well.

thanks Jimmy!

[petrklus]

Just checking on this - has there been any movement on the radiator valve support?

[hmerk]

closed due to inactivity

[lolodomo]

We can at least add that a refactoring of the binding is in progress and I believe it includes the valve support. @clinique for confirmation

[clinique]

We can at least add that a refactoring of the binding is in progress and I believe it includes the valve support. @clinique for confirmation

I confirm that valves are present in it. Anyone can have a test.

[lolodomo]

I suggest to reopen this issue and that you reference it in your PR ?