In general, all routers will route (technically it’s possible that a router can be configured not to route, and there are some applications for this, but it’s very unlikely that a standard commercial bulb would not route).
But the Osram is a plug socket… Not a bulb.
Is there anyway to test/tell? When I´m walking around our house with the dimmer switch in my hand, I can only tell something is wrong, when I push one of the buttons and it starts blinking red. I assume this mean, that the command didn´t get through to the coordinator. Other places in our house it gives a green blink when it works. I then moved the Osram plug to see if it makes any differences, which is didnt. Thats why I think there is something odd going on with the MESH…
I have a few Philips light bulbs as well, though they´re not connected to the coordinator. I might give one of them a try to see whats happens. Just need to figure how to clear/reset them and get them added to the Zigbee coordinator. I have never tried adding a bulb before.
It doesn’t matter - all mains powered devices are routers.
I’m not super sure how well this would ever work? A child device would need to reconnect to the network via a different parent if you moved it. I’m not sure how long this all takes, but it will take some time.
You can always check the routing tables, but in your dynamic situation, it’s probably not going to work very well. You should check the sniffer to see what is happening.
I have changed the MESH to 5 minutes in the coordinator setup, though I have if it have any influence on anything.
But you´re right, I cant use the dimmer switch, if things are taking too long to reconnect…
I have now added a Hue bulb (it was easier than expected. Just clear the bulb from the Hue bridge, and the coordinator then found it). Maybe something will change then.
Where can I check this routing table?
If I understand correctly, you changed the child aging? This is unrelated - when you move a device, it will need to find a new parent irrespective.
It’s in the properties isn’t it?
No, the option, Mesh Update Period. Its default to 1 day. I have changed that to 5 minutes.
Hmm… Not sure what you mean then… This is the proberties of the Hue Dimmer Switch:
And this is for the Osram plug socket:
Ok - this is totally unrelated so will make no difference at all.
Okay… Whats the option for then?
Btw… did you see my screenshots of the properties?
It updates the mesh information in the properties - it doesn’t actually update routing as that is done on the fly.
Yes, but as I said, in your case I don’t think it’s going to be very useful as you are moving things around.
It looks the same for the Orsram plug socket, even when I dont move it.
The Hue bulb I just added does seem to have an route info though.
I use this binding with linux, xbee-stick and ubisys devices for months now without any problem: thanks very, very much chris!!! (are you still thinking about integrating an update mechanism for the firmware of the devices?)
I would like to add vibration sensors for doors and windows. Following the informations given on the binding page the smartthings sensor offers that detection but only in the version of 2015. The 2018 version doesn’t show a “vibration” channel.
Does anyone have experience with vibration sensors, perhaps even combined with contact sensors?
The binding already supports OTA upgrades - I added this about 18 months ago (although I did get a report recently that it’s not working on some devices due to a timeout with the final handshake).
What isn’t available is a firmware provider - this is something that was planned for ESH, but there is no public implementation available. Without this, it doesn’t work.
Hi chris,
just came back home from work and you already answered - really great “service”
Hi @chris
I´m not sure if anyone actually have reported this.
Today I bought an Aqara door/window sensor just to test. To my understanding Aqara things are Xiaomi 2.edition zigbee stuff… I have given up trying to get the 1. edition door/window sensor to work. It can add, but it doesnt change state.
Anyway, the Aqara sensor added just fine. But it only apply a switch channel. It does seem to work fine though.
Unfortunaly this sensor report state is ON and OFF , which doesnt really make any sense, for a door/window sensor, which in my opinion should be a contact and state OPEN/CLOSED.
Second, its state is OFF when the magnet is put together, and ON when it´s apart. This is strange as well, I think. But again, ON/OFF is strange in itself.
Third, there is no kind of battery channel what so ever… This is not good at all. A door/window battery sensor without a battery channel/report just isn´t a great idea, specially if it´s used for security/alarm.
I wonder if this is due to the binding not fully support the device?
The sensor reports contact, battery, voltage and link quality. I am using two of the Aqara door/window sensors with zigbee2mqtt. Currently this seems to be the best solution for openHAB users that want to connect their Xiaomi stuff.
What does that mean exactly? I’m not sure that any Xiaomi devices are actually ZigBee compliant, but I might be wrong. I don’t know what “2.edition zigbee” means though?
Then you should use transformations to change this - it’s not something that can easily be done in the binding - if the device reports as a switch rather than a door sensor, then that’s how the binding will present it. I don’t think it’s that hard to manage this?
I don’t know what the device supports, so it’s hard for me to comment on this. Again, the binding checks for known functions to report battery - if the device supports them, then battery will be displayed - if it doesn’t support it, then it wont. If the device is using a non-standard feature, then it probably won’t work.
Hmm, thats odd. I tried add it three times, all three times discovery went fine, however only a switch channel is recognized…
As said, It´s my understanding. It may be wrong. But Xiaomi have the Mi series (which doesnt work with a zigbee coordinator) and then Xiaomi has the Aqara series. The physical look is slightly different for the two door/window devices.
This is the Mi sensor:
And this is the Aqara sensor:
According to rumors and others, Aqara series devices are known to be “more” zigbee compliant.
Of couse if thats what the sensor reports, then thats how it´s suppose to be, and should be fixed by transformation… But my concern is/was wether the report is wrong. As you can see from Manuel above, his sensor report a contact and even battery voltage and link quality… I guess this means something went wrong during the discovery anyway or??
I know you cant comment on devices you dont know, and I dont expect you to either. But according to Manuel above, this device support contact, battery voltage and link quality… I´m not quite sure if there is any differences between zigbee2mqtt and “ordinary” zigbee… I thought it was the same. Maybe thats the issue here?
Ah yes, the well know “more zigbee compliant” level of compliance to the standards 
. I know that they are using some parts of ZigBee, but what does that mean? We also know that there are non-compliances - again - it doesn’t really help. Unless devices stick to the standards, don’t expect them to work fully in a ZigBee environment.
We know that these devices don’t work well in a mesh system - this has been documented in many places. Maybe they have or will improve this, but please don’t think that “more zigbee complaint” means anything. It’s like telling the police that speeding at 20km over the speed limit is “more legal” than speeding at 30km over the speed limit - it’s still not compliant with the law.
zigbee2mqtt uses parts from zigbee-shepherd (an open-source ZigBee gateway) to translate from manufacturer-specific zigbee to something “common”. This is what some other zigbee implementations (for example in ioBroker) do as well.
In order to do this sort of “translation” - it requires someone who has the device, and I personally don’t.