Ok, should I keep using the binding without polling or should I update this library too?
Yes, I’d suggest to keep using that for now - otherwise I think your system will have congestion issues again until polling is improved.
I dont get it…
Nothing at all happens when I trigger (push) the Dimm Up, Dimm Down.
The Buttons I/O works, but they seem somehow connected.
When I press the ButtonI my switch goes ON allright. And when I press the ButtonO, my switch goes off. But this is due to a rule.
Nothing happens if I push the ButtonO… I get no log from it.
Wether or not they´re beeing trigger channels, I suspect they all should work as switches?
These are mig linked items:
Switch HueSwitch1 "Hue switch button 1 [%s]" <switch> { channel="zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI" }
Switch HueSwitch2 "Hue switchbuton 2 [%s]" <switch> { channel="zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO" }
Switch HueSwitchDimUp "Hue switch Dimm Up [%s]" { channel="zigbee:philips_rwl021:4beca465:001788011032a21b:dimUp" }
Switch HueSwitchDimDwn "Hue switch Dimm Down [%s] " { channel="zigbee:philips_rwl021:4beca465:001788011032a21b:dimDown" }
Number HueSwitch1_batteryPercent "Hue switch1 Battery percent [%.0f %%]" <Battery> (BatteriLevel) { channel="zigbee:philips_rwl021:4beca465:001788011032a21b:batteryLevel" }
Number:ElectricPotential HueSwitch1_batteryVoltage "Hue switch1 Battery voltage [%s]" <Energy> { channel="zigbee:philips_rwl021:4beca465:001788011032a21b:batteryVoltage" }
And this my rule to trigger the Hueswitch1.
(actually this only turn my Osram plugh ON/OFF).
rule "test Pilips hue switch ON"
when
Item HueSwitch1 changed to ON
then
OsramPlug_OnOff.sendCommand(ON)
end
rule "test Pilips hue switch OFF"
when
Item HueSwitch1 changed to OFF
then
OsramPlug_OnOff.sendCommand(OFF)
end
The rule work fine, using the Buttons I/O…
2019-03-03 18:09:15.613 [vent.ItemStateChangedEvent] - HueSwitch1 changed from ON to OFF
2019-03-03 18:11:06.609 [vent.ItemStateChangedEvent] - HueSwitch1 changed from OFF to ON
2019-03-03 18:11:10.188 [vent.ItemStateChangedEvent] - HueSwitch1 changed from ON to OFF
2019-03-03 18:11:21.163 [vent.ItemStateChangedEvent] - HueSwitch1 changed from OFF to ON
2019-03-03 18:11:22.836 [vent.ItemStateChangedEvent] - HueSwitch1 changed from ON to OFF
2019-03-03 18:11:25.563 [vent.ItemStateChangedEvent] - HueSwitch1 changed from OFF to ON
2019-03-03 18:11:27.132 [vent.ItemStateChangedEvent] - HueSwitch1 changed from ON to OFF
But as said… It seems like the buttonsI/O is connected and therefore not useable as individuals.
Nothing at all happens, when I push the DimmUp/down.
in events.log you should get something like (note: I don’t own a hue switch, log is from a bitron video)
2019-03-03 18:22:00.803 [vent.ChannelTriggeredEvent] - zigbee:bitron-video-902010-23:706002137:00124b000955b140:key1 triggered SHORT_PRESSED
What do you see for ButtonI, ButtonO, and the DimButtons?
I don’t think so. But I could be wrong.
For ButtionI and ButtonO, I just posted the log…
2019-03-03 18:46:24.094 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI triggered SHORT_PRESSED
2019-03-03 18:46:27.260 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO triggered SHORT_PRESSED
2019-03-03 18:46:29.617 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI triggered SHORT_PRESSED
2019-03-03 18:46:30.298 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI triggered SHORT_PRESSED
2019-03-03 18:46:31.035 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI triggered SHORT_PRESSED
2019-03-03 18:46:31.476 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI triggered SHORT_PRESSED
2019-03-03 18:46:31.777 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI triggered SHORT_PRESSED
2019-03-03 18:46:32.425 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO triggered SHORT_PRESSED
2019-03-03 18:46:32.750 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO triggered SHORT_PRESSED
2019-03-03 18:46:33.011 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO triggered SHORT_PRESSED
2019-03-03 18:46:33.242 [vent.ChannelTriggeredEvent] - zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO triggered SHORT_PRESSED
I get nothing for the DimmButtons.
So you basically only need one rule per channel (no need for switch items):
rule "Philips Hue ButtonI"
when
Channel 'zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI' triggered SHORT_PRESSED
then
if(OsramPlug_OnOff.state == OFF){
OsramPlug_OnOff.sendCommand(ON)
} else {
OsramPlug_OnOff.sendCommand(OFF)
}
end
Are you on the latest zigbee library? Support for the dim buttons was merged on 16th January, see Make dim buttons of the Philips Dimmer Switch usable. by rbi · Pull Request #352 · openhab/org.openhab.binding.zigbee · GitHub
Edit: I missed that you are on the latest snapshot… Sorry.
Unfortunately I just realised that this deployment failed 
. I’ve just run it again now and it was successful…
Well, this switch works as it´s designed for. The ButtonI/O will toggle my item HueSwitch1. HueSwitch2 will never get triggered, as far as I understand. It´s a bit ackward I would say. But it´s probably due to the design of the Dimmer Switch.
As far as the DimUp/down. They are probably designed the same as the ButtonI/O. But in my case, I get no respons at all. So I cant tell.
Yes updated a few hours ago…
My point I was trying to get to yesterday (I shouldn’t write, when I’m tired…):
I think your impression of awkwardness comes from a little misconception.
Real world: You press ButtonI (you don’t hold it, it doesn’t stay ON), the Osram plug goes on; you press ButtonO (again you don’t hold it, it doesn’t stay ON), the Osram plug goes on.
So for me it’s not the most logical way to bind a switch to that channel, because the channel itself never gets or indicates a state as ON or OFF, it notifies only that it was pressed. The outcome of pressing the button you can see at the plug, it goes ON or OFF.
Therefore translated to openhab:
rule "Philips Hue ButtonI"
when
Channel 'zigbee:philips_rwl021:4beca465:001788011032a21b:buttonI' triggered SHORT_PRESSED
then
OsramPlug_OnOff.sendCommand(ON)
end
rule "Philips Hue ButtonO"
when
Channel 'zigbee:philips_rwl021:4beca465:001788011032a21b:buttonO' triggered SHORT_PRESSED
then
OsramPlug_OnOff.sendCommand(OFF)
end
In that way you have a clean relation between the ButtonsI/O and what it is happening in your openhab logic. Then you also don’t need the confusing items HueSwitch1 and HueSwitch2 (By the way: I can’t explain the magic happening, why HueSwitch1 is actually toggling between ON and OFF…).
I can’t tell, why you don’t get any response from DimUp/Down. But did you try clearing the cache?
Correct… The reason why it´s linked to a switch is because thats the way the Dimmer Swich worked before I updated the binding/lib´s.
Infact, it´s pretty odd. (This is very hard to explain)
I have not remove the “old” Thing yet. But I have removed the linked items channels of the Thing. But the switch channel still shows as linked… It somehow seem connected to the “new” Thing and it´s channels…Shouldn´t be possible.
This is ofcouse the correct way of doing the rule, cause it doesnt need a linked switch.
I think the reason is, due to what i explained above… The “old” Thing is still there, and the Switch channel still shows linked, even though I have removed the link to that Thing… It´s weird, and I fail to understand how this is possible…
I will remove the “old” Thing tonight an see what happens. Beside I will no longer be able to see the switch item toggling, I believe would still working. And ofcouse change the rule to use the Thing channels insted.
I removed the “old” Dimmer Switch Thing… For some reason it had stopped working…
Then I removed the “new” Dimmer Switch Thing and made an new discovery. Binding found the switch, I added it. But it still doesn´t work…
I have changed the rule to use the channels I/O. But nothing happens. When I push either of the buttons, I get no respond at all in the log… The thing is online allright according to PaperUI.
EDIT…
Now it workes again… I removed and added the dimmer switch again… And then it worked. DimUp and DimDown works fine as well. Strange…
Hey there,
Does anyone of you fellas have experience with the YULED (SR-9100, wallbox mounted) Dimmer switch ? It’s supposed to have two channels for control. First for dimming intensity/state and second for switching on/off.
Nevertheless the on/off channel seems to be missing in the thing.
Tried to pair it once again, as it could be a configuration problem during handshake or so, but i just keep getting the dimming value.
Ist there an option to manually declare channels?
Thanks in advance 
A few months back they did a channel consolidation and removed redundant channels. A dimmer channel can also turn things on and off so the on off was removed. You can still configure a a dimmer item and a switch item and link them both with that dimmer channel. This will allow you to interact with the device as you are expecting.
For information, I found that the maximum timeout in the Ember stack is around 27 seconds, so I guess that this is not actually a bug in your dongle 
.
Hi @chris,
But, at least in the Telegesis, it seems to be configurable, and the default MAC timeout is ~7 seconds.
In any case, as the dongles could hold transactions that much, and at least it seems consistent between Ember and Telegesis, would it make sense to increase the transaction timeout to 30 seconds? (or maybe only for dongles reporting RX_ACK/NAK?)
Pedro
Of course it will be consistent - they are the same thing after all . The only difference really is that the Telegesis uses an AT interface.
Yes, I think this is sensible.
Also FYI, I plan to change the default “sleepy” state to be non-sleepy. Currently this is causing big problems with new devices joining the network as the join is very slow.
It seems to makes sense, but I wonder why: if a single device is joining, and there is no load, being sleepy or non sleepy makes no differece in terms of the transaction manager… There should be enough non-sleepy slots, as anyway we would never be sending more than two transactions to the same device as per queue policy…
So maybe the slowness could come from other place?
Anyway I only see an issue in doing so if you have several new devices joining the network at the same time, so it should be OK as this is not the usual case happening.
Could I suggest anyway that the device discovery service ensures the very first thing to be discovered from a device is the node descriptor, so that if this is pending it will not “try discover” anything else, such as the endpoints or the neighbours?
I think I saw in the past also routes being discovered for end devices, and as I recall, I think it happened because on the discoverer, the ROUTE discovery task is removed if the device type == END_DEVICE,
but at the beginning it is UNKNOWN, so this check does not match, of course…
Pedro
Well, there are 2 impacts when a device is sleepy - you are thinking about the “non-sleepy slots” - but the other issue is the queue management is different. This could maybe do with some improvement, but it is the main contributor - not the number of slots.
This does not help. Remember that the sleepy state is updated during the node update callback - this is at the end of the discovery, so the order of discovery doesn’t matter.
I think you are thinking about the mesh update. With the mesh update task, we don’t download the routing table from end devices (as they don’t respond, and probably don’t have a route table). This is not related to route discovery which is handled when messages are sent - not in the discovery task.
As discovery is considered complete (as I recall) when both node descriptor and endpoints are discovered, maybe then it would make sense to prioritize these two (instead of just the node descriptor)?
Not speaking about zigbee protocor routing & discovery (just in case), but about the ZigBeeNodeServiceDiscoverer. This is managing (if I understood well the process) the initial discovery of the node also.
My undertanding is that routing discovery task, neighbourg discovery task, etc, should only be executed once the node is discovered (or is it already like this, and I missed something?).
Pedro
I think that’s the way it is now, but I will check. Possibly the node added call is not made though until all the initial discovery tasks are complete (ie including the mesh info calls). I guess this is what you are getting at? I will check that as it may help a little during discovery, which is of course a busy time…
It is performed at the end of the discovery, and then periodically if the mesh update is configured.
I see your point now though and I’ll have a look at that - you might be right that this task is being performed during initial discovery even on EDs. I don’t think that’s an impact on the above issues I’ve seen in any case, as the slow discovery is also there for routers when they are still considered to be an ED.