I would strongly recommend not doing this. It will cause additional traffic that is likely to delay sending of data needed for the discovery. I think this is one of those things where you do something, and it happens to work, so you inadvertently attribute it to that event.
The CLI is not written for openHAB. It is a general CLI used for testing the low level ZigBee framework - it is just imported into OH for the same purpose. The binding uses different means to decide if a device is online.
If it’s confusing we can remove the CLI?
I can only reitterate what I’ve said. The binding will systematically search through all endpoints looking for services that it can support through a channel. Either the discovery was incomplete, or the device doesn’t support any functions that the binding can use.
That’s not uncommon. There are many different systems employed by battery devices and some are not necessarily respecting the rules…
I believe that battery is reported in a custom cluster so is not supported by the binding - you’d have to ask Xiaomi why they didn’t use standard functions here.
Likewise, the signal integrity is monitored by the binding using standard functions - and not the Xiaomi specific function.
The binding uses different means to decide if a device is online.
If it’s confusing we can remove the CLI?
I think that will cause even more problems that it solves.
A note in the general help that the online/unknown state in the CLI may differ to the GUI should be sufficient
(Today 3 of the Ikea bulbs were showing online in the CLI and offline in the GUI. Sigh… They came back by toggling the devices disabled/enabled in paperui so they can’t have been too far gone but it’s a little worrying - and just to add to the confusion they were showing updates in the logfile despite the GUI thinking they were offline)
[re battery deviecs and long wakeup intervals]
That’s not uncommon.
Is there any way to accomodate this? Ideally whilst flagging that the device implementation is non-compliant but it’s being accepted anyway?
I think the Robustness principle/Postel’s law applies here (RFC 1122)
[yes, I know the counterpoints to this, having contributed to the Internet drafts. Martin Thomson’s point is valid. Flagging noncompliance both helps ensure people don’t make assumptions and puts pressure on suppliers to fix things]
I believe that battery is reported in a custom cluster so is not supported by the binding
I’m not entirely sure what you mean by a custom cluster
The way I read the coverage is that it’s reported as part of the return line for each of the sensors. zigbee2mqtt shows battery status/battery mV/signalquality/sensor for each sensor at every sensor update and it appears to be embedded in there when looking at the raw return string.
Sorry - I don’t actually know what the issue is? Does it matter if it doesn’t wake up every 7 seconds- normally not. It will simply mean you need to manually wake up the device if you want to change the configuration - on these devices, that is normally approximately never, so it should not impact the devices support.
Or do I misunderstand what you mean here?
It’s non-standard - ie not defined by the ZigBee standard. There is a standard way to report battery level, and this device does something non-standard.
This has been discussed previously - unfortunately at the moment it is not something that I personally intend to support as I simply have too much else on my plate so I try to focus on supporting standard ZigBee devices at the moment. If someone else wants to add this support, and it doesn’t compromise the structure of the binding, then that is of course great
Noted regarding busy-ness but if there’s a ticket then someone might look at it.
I assume for the purposes of sorting the things out on a longer term basis that an official xiaomi specification would be the best thing you (or anyone else) could lay your hands on?
It was looked at in the past and discussed here -:
The problem is that this is really non-standard. The binding is designed to handle non-standard attributes, but unfortunately in this case they’ve not even used standard ZigBee concepts, so it would require probably a custom handler which could be done through a new completely binding extension.
The issue is primarily the door/window switches - they’re “dropping out” and being reported as offline after a while (3-6 hours), which makes my noddy scripts using their status go loopy (I’m intending to use these to control radiator valves - open window == no point in attempting to heat the room)
The things rejoin instantly when the status does change from ON to OFF or vice versa. The problem is that in the meantime the magnet sensor is reporting neither ON or OFF
Unlike cheaper magnet sensors which simply report a “state change” when a door/window is opened (nothing when the door/window is closed), these units actually give “on/off” results, which means keeping them online or caching their results is relatively important as a result.
The thermometers are less critical if they drop out - they do rejoin instantly when things change. The big problem I’m encountering at the moment is initializing them - until “device initialised” is true, they simply display NaN in the PaperUI control panel and they’re consistently failing on pressure sensor initialization (they may eventually synchronise but it’s taking anywhere between 5 and 40 minutes of attempts to make this happen and the more sensors there are the harder it seems to becomes (I’m up to 12 of these units in the mesh and likely to want to add another 8)
Understood - but having the document is a reasonable step to understanding how badly they’ve borked things without having to rely on guesswork
My experience dealing with chinese designers is that once you get past the “Why on earth are you crazy enough to want to do that?” barrier they can be extremely helpful (especially when they realise they can usually ship more product by publishing their specs without NDA encumberances, or by moving to “standardised” specs in firmware updates), but they tend to start with a mindset of not thinking about interoperabliity. The number of reinvented wheels you run into is staggering even at companies like Huawei in their network kit (Lots of custom SNMP MIBs here instead of using standard ones, then when customers complain loudly about not being able to use standard NMS software the response is to “use our software”)
Just a reminder that a Thing OFFLINE/ONLINE status is not an accurate mirror of target device status.
A sleeping battery device may be ONLINE, as might one smashed with a hammer.
An OFFLINE Thing can pass along communications (else how would we ever find out a device is alive?)
2 restarts later and the json for the cc22531 in org.eclipse.smarthome.core.thing.Thing.json is now reset to what appears to be factory defaults - and won’t take changes (alterations take in the gui, but they don’t survive a restart)
I’ve lost control of PANID, Extended PANID, channel and mesh update period
Surprisingly the network key is unchanged - but of course with all the above having changed I’ve lost the entire mesh. A re-paired device won’t stay paired after a OH restart (but will survive the stick being pulled out/reinserted, etc whilst OH is running - this is pointing towards a OH issue rather than a device issue.)
Altering the json whilst openhab is stopped doesn’t take either
I’ve never set any manual files for things in /etc/openhab2/ so I’m not sure what’s going on.
Yes but losing the existing sensor status when this happens is breaking other stuff.
Door/window sensors are the kind of items where data may not change for days on end.
Whilst the Things in question reappear instantly when a door/window is opened or closed, the problem is that the presumed current status of that object can’t be read
Why is this a problem though? We normally do not read the state - these device must instead report their state autonomously.
We don’t tend to poll devices - they are configured to report. You don’t want to be polling a device every 10 seconds, or the battery will go flat. Additionally, you don’t want to be polling a door sensor every 10 seconds anyway as the door can be opened and closed in that time, so you’d miss it.
Devices need to report their state through reporting - instantly.
We’d expect an Item state to remain valid in between “stuff happening” e.g. if a battery device periodically reports “closed”, our Item retains “closed” between the reports.
As I understand @Stoatwblr problem, after lots of sidetrack about USB communication and Thing status, they’re now saying Items are not behaving like that? (Though I’ve no idea what they are doing instead.)
You’re right - we have been kind of drifting between issues and maybe it’s worth taking a step back. @Stoatwblr can you describe the issue you’re having? It’s probably best to start a new thread as well if it’s no longer related to this original issue.
Ok, so you’re talking about within openhab - not the binding? So you mean when a device is OFFLINE, you can no longer see the status?
I guess then we need to work out why your devices are going OFFLINE. This discussion started by you asking about the polling of the devices every 6 to 8 seconds (or the devices waking up every 6 to 8 seconds, which to me is the same). That has nothing to do with the online status of a device - we need to work out why your devices are going offline then.
I’d suggest to check the logs to see what is going on. There will be logging in the binding logs about the alive tracker. Let’s see what that says.
Apologies for the confusion - we are changing topics a lot here. I’d suggest to start a new thread, clearly stating what the issue is.
Where o where? You haven’t mentioned Item at all. Item.state is where we expect any presumed status to be held, regardless of any communication churning about. What state do you get instead?
To recap; Things are about managing comms with devices, and know nothing about meaningful data e.g. temperature readings.
That’s the business of channels, interpreting data.
But channels are stateless, passing messages only. Items hold data with duration over time, between messages.
