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.
I just had a look at the code - the routing table is not requested during initial discovery - only during mesh update if the type is a router. The neighbour table is however requested - this is āokā, but I think you are right that an optimisation here is to remove this from discovery.
The only other request is the power descriptor - I think it is safer to have this before the discovery completes so we have the complete picture of the node.
Is this always happening or only under busy network?
If there is no load, let me explain why I think this should not be affecting (and hence my doubts). If the node descriptor was the very first thing to be discovered, it is just one outgoing command: it cannot delay the whole discovery.
As indeed we do not update the queue till the endpoints are discovered, endpoint discovery may still take several commands: this might delay things only if there are several other discoveries ongoing or the sleepy queue is full, but if it is not, there shoud be no difference.
Thatās why I ask: if there is no load, even if the slowness seems to come from this, there must be another reason (even if it is somehow a side effect, I would like to figure out why), and maybe it is because somehow we are trying to complete route discovery, neighbour discovery, and child discovery, etc, before calling nodeUpdated? If node descriptor and endpoints are not sometimes the very first thing to be discovered, this may produce the effect of the whole discovery being delayed, but again this should only happen under loadā¦
Pedro
Itās always there.
Yes, there is - as I said above, it is not related to the isSleepy state - it is related to the queue itself (ie the fact that the queue profile is different). Iāll explain further below.
No - this is not the case - other than neighbours. I have a PR to go that will remove this, but it is in any case not the issue.
So, as mentioned earlier, the issue is not the isSleepy() state - the issue is the queue profile. The issue is that the queue has a minimum time between commands, and for sleepy queues, this is quite long (7.6 seconds!). Thinking about this some more, and I donāt think this is needed at all - we can drop this to the same as non-sleepy queues (50ms) and instead set the maximum number of outstanding transactions in sleepy queues to 1. This will mean that the pacing will be 50ms minimum between commands, but if a command completes it will send the next immediately (assuming itās more than 50ms), and if it doesnāt complete, it will respect the 1 frame outstanding requirement imposed by the parent queue size in the router.
That should (I think) solve this 
FYI Iāve created two PRs -:
Iāll give this a test shortly to make sure it resolves what I was seeing, but any comments welcome as always 
Thanks.
Iāve now deployed an updated 1.1.11-SNAPSHOT of the ZigBee libraries. I would appreciate any further comments on the performance of this version - if there are no major issues in the next few days I will roll this out into the openHAB target platform so that it is available for everyone with the openHAB 2.5 snapshots.
To use the latest snapshot, see this thread for the update script -:
1 Like
Hey - Iām just getting back home so little late getting to install this new update - I donāt see this committed to master so how am I able to install this? I tried selecting dev and specifying the level but no luck. Are you pushing this to master? Iāve not had issue installing those.