[netatmo] Things linked to the bridge "netatmo:home" doesn't work after OH 4.x #15928
Comments
|
I have the same problem with the same devices. After trying to discover what was going on, I disabled and re-enabled multiple times both the Bridge and the Things, I started receiving MAXIMUM_USAGE_REACHED error from Netatmo API. I guess there some memory-leaks because after disabling all the Bridges and the Things, I still have these logs (after several minutes): I am using docker. |
I observed this from time to time on my prod environment but I currently fail reproducing it in dev. I know the problem exists and would love fix it... |
|
Can you please update the issue title because of course the netatmo generally works in OH 4.x. |
But, in my case, after the upgrade to 4.0 from 3.5, the binding Netatmo Energy doesn't work. It works on fresh install of OH 3.5 and it doesn't work on fresh install of OH 4.1 |
|
If the problem concerns the thermostat, please mention it. The binding is working well for me, so there is no general problem but rather a problem with particular devices, I guess. |
The problem, in my case, is not related to the thermostat, but to all the things/bridges linked to "Home". I did the following steps in a clean environment:
These are the logs of the previous steps: The responses are correct and performed without problems, but the "Room" and "Plug" are still stuck on UNKNOWN status:
Items linked to "Home" channels are working fine, but things linked to "Room" or "Plug" channels are not working. Furthermore I notice that if I save the "Home Bridge" (even if I do not change any properties) the status of the bridge is stuck in UNKNOWN. The only way to unlock it is to disable and re-enable it:
|
|
I think I found that the problem is related to the deserialization of The configuration of .registerTypeAdapter(HomeStatus.class,
(JsonDeserializer<HomeStatus>) (json, type, context) -> context.deserialize(json,
json.getAsJsonObject().has("persons") ? NAHomeStatus.Security.class
: NAHomeStatus.Energy.class))
.registerTypeAdapter(HomeData.class,
(JsonDeserializer<HomeData>) (json, type, context) -> context.deserialize(json,
json.getAsJsonObject().has("therm_mode") ? HomeData.Energy.class
: HomeData.Security.class))In my scenario, where I have both /api/homesdata {
"body": {
"homes": [
{
...
"rooms": [
...
],
"modules": [
{
"type": "NACamera",
...
},
{
"type": "NAPlug",
...
},
{
"type": "NATherm1",
...
}
],
"temperature_control_mode": "heating",
"therm_mode": "schedule",
"therm_setpoint_default_duration": 180,
"persons": [
...
],
"schedules": [
...
]
}
],
"user": {}
},
"status": "ok",
"time_exec": 0.050824880599975586,
"time_server": 1701817075
}/api/homestatus {
"status": "ok",
"time_server": 1701817379,
"body": {
"home": {
...
"rooms": [
...
],
"modules": [
...
],
"persons": [
...
]
},
"errors": [
...
]
}
}Based on the configuration of
I did a test forcing the usage of I thought to propose a change, but I am not a Java expert not even on the binding source code and logic. @clinique what do you think? |
|
Can you provide your things definition? |
Matt2cv
changed the title
jlaur
changed the title
|
Here it is: |
|
same here, my homes data:
|
|
@simone-giudici , can you please test this |
|
I tried to install the binding in a clean 4.1.0-SNAPSHOT environment, but it does not work: Maybe I am doing something wrong. |
|
@simone-giudici : you may need to grand your bridge on this new environment. On my side it works in dev. |
|
Sorry, but I don't know what you mean with "grant your bridge". The openHAB version on which I did the test is: Adding
Adding
|
|
Do you have some other binding installed alongside ? I made a test on a clean environment and faced the same issue than you. I had the Zigbee binding installed - removed it and then everything worked. Very weird. |
|
I did it on a clean environment, just downloaded from openHAB site. |
By the way, working on it, I think I identified two culprits of this. Will create a dedicated PR. |
|
@simone-giudici : can you please try this new one |
|
I tried also this new one without success. As the binding installed from the marketplace starts, I looked at the logs to try to figure out the differences and I found that it seems to be something related to OSGi dependency resolution. What I saw is that the marketplace binding, before starting the activation of But when I install the binding from the openhab-jar.log As the logs are very long, I attached them as a file. |
|
This seems to be core related. I don't understand why it impacts this PR as no modification is done on NetatmoHandlerFactory here, nor on pom.xml file. @lolodomo : would you have a bright idea ? |
|
I agree with you. I tried to build the binding from the Anyway, I cherry-picked your commit in version 4.0.3 (my productive environment) and at first look it seems working. Could it be related to a missing initialization of Sorry for the delay in my answers but near Christmas I am always busy 😄 |
|
You should try to cherrypick this PR #15866, it solves this issue. |
|
I cherrypick partially #15866 because some changes are not compatible. |
Expected Behavior
I was in version 3.4 of OH. I had configured the Netatmo binding. The relays, thermostat, people linked to the Welcome camera, everything worked. When I upgraded to 4.0, the relay and thermostat went to UNKNOWN status. The camera part works for the moment.
Current Behavior
When I activate the netatmo account, everything goes well
Same thing when I activate the "netatmo:home" thing, everything is OK
When I activate the "netatmo:plug" thing, the relay, it tells me that it can connect
But, it remains at UNKNOWN
Steps to Reproduce (for Bugs)
To test, if the problem was coming from, I created a new token, and then, in Docker, I created 2 containers:
The 2 installations are clean with only the Netatmo binding to install
I first tried setting up the 4.1 container. Same problem as on my OH 4.0, the "netatmo:plug" things linked to the "netatmo:home" bridge go UNKNOW.
Then, I configured the 3.4.5 container with the same token as the 4.1, and everything continued, the "netatmo:plug" things went ONLINE.
In addition, in version 3.4.5, OH sees 17 things after scanning compared to 7 in version 4.1
Your Environment
My main OH 4.0.4 works on a dedicated machine under
armbian bullseyes. The installed java isopenjdk 17.0.8 2023-07-18 LTSMy OHs under Docker run on a Debian VM. The java for OH 3.4 is
openjdk 11.0.20 2023-07-18and for OH 4.1openjdk version "17.0.9" 2023-10-17The text was updated successfully, but these errors were encountered: