Openhabian on Pi 4 running openHAB 3.2.0 Build #2454
Zigbee is Dual USB Dongle: Ember EM35x Coordinator
Sigh, it’s never easy … I’m making progress migrating all of my SmartThings setup to OpenHab and I’m now working on the various door contact sensors I have. The first one I am trying to move over is a SmartThings Multiv4 STS-MLT-950. It paired immediately and showed up so I was excited that it was going to “just work” … well unfortunately no. It reporting the following channels:
CIE System Alarm (Switch)
Temperature (Number:Temperature)
Tamper (Switch)
Battery Alarm (String)
Low Battery (Switch)
Battery Voltage (Number:ElectricPotential)
Binary Input (Switch)
My first thought was that it is strange there is no “Contact” Attribute. I created Items for all of the Channels to see what was working and I can only see the Temperature working.
There is no change on the device when the magnetic sensor is engaged.
This makes me think it is grabbing a generic zigbee config … @chris do you have any insights into this device? I see that a SmartThings motion sensor was updated for OH3 but no others … is there work required to move the DB to OH3?
That’s not how the binding works - the binding will scan the device to try and detect what services a device supports, and if the binding has any channels that it can provide.
To me, this looks fine - why do you think it’s it’s wrong?
Sorry - I don’t. I don’t think I have one for testing.
I’m not sure what database you mean? I think you’re getting mixed up with the Z-Wave binding?
If the device isn’t reporting, then possibly the initialisation didn’t complete. During initialisation the binding will configure the device so that it reports any changes - if this configuration didn’t happen then it won’t send reports. There is a config option to reinitialise the device so you could try that, but make sure the device is awake first, otherwise the binding will not be able to communication and the initialisation will fail.
One other possible option is the device requires ZigBee 3.0 security and I suspect that your coordinator firmware may not support that? What version of firmware are you using? If the device requires ZB3 security, then it works for a few seconds, but will then leave the network if it doesn’t get a certain exchange that it requires, and will therefore no longer communicate.
Thanks Chris … I’m definitely winging it and have little understanding of how things work, but in searching github I saw this update for the SmartThings MotionV4 sensor:
Which shows you updating it for OH3 … so I made an assumption that other devices needed to be updated. obviously incorrectly.
And this is unrelated to this post, but in that code it shows the Motionv4 with Illuminance channel which I don’t believe exists. I posted about that here:
Anyway, back to this issue, the device is reporting Temperature regularly so I am assuming it wakes up to do that. If I disable and re-enable it the device comes back online. I turned on the various zigbee debug logs and disabled it, and then reenabled it and waited it to show online then selected Initialize and hit save. Here is the log (filtered just for this device):
Well sorry @chris … I just went through a third re-pairing process and now the Contact is reporting when open/closed … maddening … sorry for wasting your time. Thanks again.
Just FYI, there are a small number of thing definitions for devices that are not following standards. For most devices, the binding detects the devices features and creates the channels accordingly. There are maybe a dozen or so devices that are defined manually because they don’t follow the standard in some way and that’s what you have found in your reference above.
Regarding the other issue … why did you use Illuminance instead of Temperature for that device?
Model STS-IRM-250 (i.e. motionv4) supports occupancy and temperature
I’m not sure - it might be a mistake but I don’t have this device to test with. If so, maybe someone using this can update the configuration - that would be great.
Thanks Chris - you mean someone who has the device and also knows how to update the configuration? That would be really great as I suspect it will solve my and others issues with the device.
It’s best if this is the case as it can be a pain to test, but if there’s no-one that fits these criterea, then if you provide the XML file for this device (from the userdata / network folder) I will take a look and see if I can update this. It might just be as simple as changing the channel names, but it’s best to check.
I know how to add files to the addons folder and start/stop them in the console … question: Do I need to upload all of these files even if I am only used the Ember bridge? I tried adding the zigbee binding and the ember bridge, But, after adding just those two, the bundle:list status, shows other zigbee Addons in the “Waiting” state …
FYI in case someone else stumbles on this thread … I had a Duh moment when I realized I needed to Delete the zigbee device and re-add it in order for the Temperature Attribute to show up. Makes sense, but it wasn’t obvious to me. Now I can report that the device works as it should and has both Motion and Temperature (i.e. not Illumination).
So, just for info (and again to help others) - you shouldn’t really need to do this, but it’s one way. Let me try and explain what happens.
If there’s some sort of error during the initial join, then the binding may not be able to interview the device fully in order to discover all of its features. This could leave it without some channels (or even all channels!), This issue is especially common on some battery devices that may go to sleep really quickly after joining (the Chinese sensors are especially bad and need to have a button pressed every second or so for a few seconds after joining).
If this happens, there are two options. The first is what you’ve done above, and re-add the device, but it’s probably not the best approach.
There is an option in the devices configuration called something like “Reinitialise”. Setting this to true and saving the configuration will cause the device to be reinterviewed - the same as when it was joined. So long as the device is awake, this will allow the channels to be created.
I would generally recommend trying this first, and trying the re-add option if this fails.
I hope that helps explain the “what and why” at least a little
(I will also try and put something into the docs about this)
I’m not sure what database you mean? I think you’re getting mixed up with the Z-Wave binding?
that other devices needed to be updated. obviously incorrectly.