Hello,
Just switched to DeCONZ and have an issue with the subject device.
It works fine but I’m seeing a lot of “unreachable” devices now and then. The other devices I have resync when they reconnect but this one goes to closed and stays there. At least it did for 9 hrs as that’s the longest I gave it to check.
I do find it a bit odd that the ON state is considered closed and OFF open, I think that’s backwards but whatever.
I found a lot of threads about Aqara sensors not syncing properly and it’s been confirmed as a bug.
Could this be involved I’m wondering?
If it isn’t, is there a way to force a resync on reconnection?
I have automations that rely on the status of this device so it can be a problem for me.
You have a long post here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6469#issuecomment-1307527173
With a DDF to try.
But for the open/close issue, I need someone able to compile the code to test a patch.
Not any change.
I’ll hope it’s just related to the bug reported and the fix for that fixes this I guess.
Thanks.
But its the roller that are marked as unrecheable ?
Can you share the device json of an unrecheable sensor ? Taken from phoscon/help/Api Information/Sensor ?
I assume you want the switch, not the sensor. The only sensor it has is the battery, the switch is the actual control of it.
But here’s both:
"5": {
"capabilities": {
"alerts": [
"none",
"select",
"lselect"
]
},
"config": {
"groups": []
},
"etag": "c043ef3e47de72f9b873df431c738da8",
"hascolor": false,
"lastannounced": "2023-01-26T08:42:56Z",
"lastseen": "2023-01-26T10:42Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.acn002",
"name": "Window covering device 5",
"state": {
"alert": "none",
"bri": 254,
"lift": 100,
"on": true,
"open": false,
"reachable": true,
"speed": 2
},
"swversion": "0.0.0_0030",
"type": "Window covering device",
"uniqueid": "54:ef:44:10:00:4a:4e:e4-01"
}
}
{
"2": {
"config": {
"on": true,
"reachable": true,
"temperature": 2200
},
"ep": 1,
"etag": "ec35a56b24565f1d42bcb42a49b5826e",
"lastannounced": "2023-01-26T08:42:56Z",
"lastseen": "2023-01-26T10:47Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.acn002",
"name": "Battery",
"state": {
"battery": 87,
"charging": false,
"lastupdated": "2023-01-26T10:46:15.660"
},
"swversion": "0.0.0_0030",
"type": "ZHABattery",
"uniqueid": "54:ef:44:10:00:4a:4e:e4-01-fcc0"
}
}
And when you have take thoses json the device was marked as unreachable ?
Because all seem fine for both
No, I have never been able to “be there” when it’s unreachable to be able to get it. I just know that it goes unreachable because it goes to closed status. I’ll try to keep a better eye on it and set an event to shoot a notification if they close outside the normal times.
Wouldn’t there be a way to poll the device for status on any change?
If the device make natural report, better to use them.
Your third app haven’t some logging feature ? Else you can use phoscon / help/ API Infomation / events.
It’s to be sure the problem is from the device, to be sure you have a reachable=false.
On the device we have sleeper = false, it’s correct but the device is a battery one, so perhaps not enought reactive for deconz check.
It actually happened again this morning.
I set up a notification to alert me when they close and I got the notification at 9:25.
I went right in to check and they were still reachable=true, but showed as closed and were actually still open as usual.
Not really sure if the notification was delayed or if they only go unreachable for a second, or how I would be able to determine the difference. The weird thing was even though they showed as reachable, I couldn’t control them at all.
Also, I noticed this device only ever connects to one other device. There’s no “mesh” with it.
Is that a limitation of the devices or the way they’re implemented in DeConz?
So the problem can be not the reachable state that go to false, but the open state that go to closed when the device is still open ? So like you said a synchronisation issue (more a bad return state from the device)
Also, I noticed this device only ever connects to one other device. There’s no “mesh” with it.
Is that a limitation of the devices or the way they’re implemented in DeConz?
How look the device color on the left of the node in deconz ? Yellow mean router, but as your device use battery it’s probably gray for end device, end device only have only 1 connexion.
Could be a sync issue but why would I not be able to control it when that happens?
Yes, it’s gray. Is there a way to tell it to connect to another device exclusively? Right now it connects to an outlet next to it, maybe it would be better if it connected directly to the Conbee?
Gray just mean it’s an end device, so not router, only 1 parent.
Right now it connects to an outlet next to it, maybe it would be better if it connected directly to the Conbee?
Ha yes can be a way to test if it’s not a router issue, what is this plug ? Osram ?
Could be a sync issue but why would I not be able to control it when that happens?
You mean when it happen , you can’t send request to the device ? Requests are made with automation or manually ? you can’t get logs during this request ? (if the device is not reachable, the API return an error message).
On the first post, you say you have this issue on some others devices too ? I think getting logs can be usefull, to check if you have no connexion issue for exemple.
The plug is a Sonoff S40 Lite. I have 4 of them, they were also reporting unreachable but since I moved the conbee I have not seen them as unreachable.
I try to send commands manually, both through my automation system (Homeseer with JowiHue plugin) and from Phoscon, neither show any change (ie I send an open, the blinds keep showing closed).
Logs from Decconz or Phoscon?
The problem there would be I run Deconz headless. So to get logs I have to vnc in, stop the deconz service, start the deconz-gui service and get the logs. While this is not a problem, stopping and starting would reestablish the connection. Not a problem for getting logs but defeats the purpose of any real troubleshooting. Can’t wait for the deconz gui to be web based!
Phoscon don’t provide log, or you need to enable the developer console in the browser. You know how it work ? error will be visible in network page.
You don’t use third app ? Only phoscon ?
But will be just http error code, if deconz said the device is unreachable, we can’t guess if it’s from the router or the device, not as useful than deconz logs.
All your roller are routed ? you don’t have one with direct connexion ?
So I’ve been running the deconz-gui instead of headless for a week or so now, not one disconnect in that time.
Not sure what the difference would be but clearly the headless service is missing something.
Lol, so if you enable the GUI to catch log there is no more issue ?
But the mode haven’t an impact on the working mode, perhaps performance issue ?
Not sure yet.
A little after I posted the previous message I went back to the headless.
So far, no disconnects. But it has gone a day without before too so still too early to tell anything.
So it did end up disconnecting again today.
Went back to the gui and am gonna let it run that way until I get a disconnect.
How are you switching mode ? headless <> desktop ?