New Netatmo binding (starting OH 3.3 M5)

[Lolodomo]

Your item NetatmoRegenmesser_Niederschlag has probably either a wrong number dimension or wrong unit set.

[alaub81 (Andreas)]

Yes. you were right. Number:Lenght was set as it is on the 1h and 24h. But here Number:Speed is the right value.

THX!

[DrRSatzteil (Thomas Lauterbach)]

Hi,

my presence camera stopped working after the update to 4.0.1 (coming from 3.4.5). I see an error on the logs:

java.lang.IllegalArgumentException: Duplicate channels netatmo:presence:d3ba4c9df5:62b748e4f51b0c0a717dd7ca:70ee5071a89c:presence#siren
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:135) ~[?:?]
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:127) ~[?:?]
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:123) ~[?:?]
        at org.openhab.core.thing.binding.builder.ThingBuilder.withChannel(ThingBuilder.java:123) ~[?:?]
        at org.openhab.core.thing.internal.update.UpdateChannelInstructionImpl.doChannel(UpdateChannelInstructionImpl.java:140) ~[?:?]
        at org.openhab.core.thing.internal.update.UpdateChannelInstructionImpl.lambda$0(UpdateChannelInstructionImpl.java:101) ~[?:?]
        at java.util.Arrays$ArrayList.forEach(Arrays.java:4204) ~[?:?]
        at org.openhab.core.thing.internal.update.UpdateChannelInstructionImpl.perform(UpdateChannelInstructionImpl.java:101) ~[?:?]
        at org.openhab.core.thing.internal.ThingManagerImpl.lambda$17(ThingManagerImpl.java:1093) ~[?:?]
        at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
        at org.openhab.core.thing.internal.ThingManagerImpl.checkAndPerformUpdate(ThingManagerImpl.java:1093) ~[?:?]
        at org.openhab.core.thing.internal.ThingManagerImpl.registerAndInitializeHandler(ThingManagerImpl.java:917) ~[?:?]
        at org.openhab.core.thing.internal.ThingManagerImpl.lambda$2(ThingManagerImpl.java:550) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        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:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]

I use the presence camera workout siren. Anyone has the same?

My doorbell thing now remains in state UNKNOWN. Before the update it was always OFFLINE. In the trace log I see only successful requests (all code 200).

[laursen (Jacob Laursen)]

@DrRSatzteil

my presence camera stopped working after the update to 4.0.1 (coming from 3.4.5). I see an error on the logs:

This is a bug:

[netatmo] Presence stays UNITITIALIZED due to Duplicate channels: presence#siren

[glhopital (Gaël L'hopital)]

PR for this issue created.

[stamate_viorel]

I am on openhab 4.0.3 and trying to add an outdoor camera all good but the camera stays unknown no matter what if I add it via UI or file based the bridges are online.
Any help ?
netatmo.log (165.0 KB)

[DrRSatzteil (Thomas Lauterbach)]

Thanks for fixing the outdoor cameras in 4.1. however I noticed on the latest milestone I can no longer control the monitoring state of my camera. The log just states:

2023-10-10 11:19:59.221 [INFO ] [andler.capability.SecurityCapability] - Monitoring changes can only be done on local camera.

However I also see the following in the messages in the trace log:

… "is_local":true,"floodlight":"auto","monitoring":"on"}]}}}

Is this a bug or is this due to my network config (the camera is on a separate vlan). However it did work like this back in OH 3.

I also checked whether the local url reported by the api matches the remotely reported local url (as specified by netatmo in the api docs) and this all seems to work as expected.

[Thomas_Hartung]

Did you manage to get it running? I have the same issue: camera remains UNKNOWN and therefore all channels contain NULL values.

[DrRSatzteil (Thomas Lauterbach)]

You need to update OH to 4.1 for the outdoor camera to work again. However there is no official release yet but only the milestone release.

[Thomas_Hartung]

Thanks, so I’ll have to wait for a stable 4.1 release. No Problem.

[sebSmarthome (Sébastien Fremion)]

Hello,
if I add a minimum humidity or co2 channel today (I haven’t tested the others) with the indoor or outdoor module, I get an error message
configuration only with web interface
openHAB 4.1.0

2023-12-27 18:11:34.535 [WARN ] [handler.capability.MeasureCapability] - Error getting measures for channel Humidity Min today, check configuration

yaml code

- id: Hummintoday
    channelTypeUID: netatmo:hum-measurement
    label: Humidite min aujourd'hui
    description: ""
    configuration:
      period: 1day

missing in configuration :
limit: MIN

if I add it manually the problem is solved

- id: Humminaujourdhui
    channelTypeUID: netatmo:hum-measurement
    label: Humidite min aujourd'hui
    description: ""
    configuration:
      limit: MIN
      period: 1day

[glhopital (Gaël L'hopital)]

I have already seen this. It seems to be a UI related issue. I never investigated further. Maybe you should open an issue in openhab mainUI repo

[AndyMt (Andreas)]

I’m running into a strange issue with my OH 4.1.1 (stable) installation (openhabian on a rPi4) and Netatmo (Weatherstation) binding.
After a while the binding starts spaming the log with dozens of messages like this:

2024-02-29 16:19:26.273 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ApiBridgeHandler of thing netatmo:account:NA_Account tried checking if channel monitoring#request-count is linked although the handler was already disposed.

After some investigations I think I know what causes it:

• When I manually pause the Netatmo account bridge, then after a resume, the messages appear every 10 minutes (which is the reconnectInverval in the things file).
• it’s also triggered when using the REST API “enable” endpoint.
• After a reboot the problem goes away.
• The issue also is caused by occasional internet connectivity issues we have at the site. After that it sometimes is the same, but not always. I assume it depends on how long that interruption lasts.

I use entirely file based configurations. Maybe that’s the problem, I haven’t tried it with UI based configuration yet.
By the way: when deleting the entire Thing file, the issue continues, so somehow the thing is not deleted internally.

My thing configuration:

Bridge netatmo:account:NA_Account "Netatmo Account"         [clientId="...", 
                                                             clientSecret="...", 
                                                             reconnectInterval=600,
                                                             readFriends=true] 
{
    Bridge weather-station NA_Main  "NA_Main"               [id="70:ee:50:13:##:##"] 
    {
        Thing indoor    NA_Bedroom  "NA_Bedroom"            [id="03:00:00:02:##:##"]
        Thing indoor    NA_Study    "NA_Study"              [id="03:00:00:02:##:##"]
        Thing indoor    NA_Snug     "NA_Snug"               [id="03:00:00:02:##:##"]
        Thing outdoor   NA_Outdoor  "NA_Outdoor"            [id="02:00:00:2e:##:##"]
    }
}

Any one having the same? Any ideas?

[glhopital (Gaël L'hopital)]

I know this issue. It happens after a module being disabled. I never found how to finally solve it.

[AndyMt (Andreas)]

I remember the Shelly binding had a similar issue. Some thread which was not terminated at dispose()? Not sure. I’ll try to find the github issue.

[AndyMt (Andreas)]

Found a comment here:

[shelly] Log "spam" after upgrade to openHAB 3.4 from 3.3

I take a quick look to the code and I can see that initialize in class ShellyBaseHandler is scheduling a thread 2 seconds later but this thread is not cancelled later, in particular in case dispose is called for any reason by the thing manager. In that case, the thread will run while the thing handler was already disposed !
I think the reason of this issue is there and it was easy to find.

I also noticed that initialize is not setting any thing status before returning, while it should. Edit: it is set at the very beginning of the init job, so it should be not so bad.