Zigbee binding

Tags: #<Tag:0x00007f01459c6a38> #<Tag:0x00007f01459c68d0>

(Arno) #1566

I think the problem with the inputs is that the binding right now doesn’t yet support any kind of remote control, right chris?

Would be helpful for this kind of device, since these Ubisys things are perfect for integrating legacy installations with zigbee lights.

(Christoph) #1567

After having some trouble getting my Zigbee Stick to work, I have integrated some devices successfully.
Because the binding documentation doesn’t list the Osram Smart+ Plug, I want to confirm that the plugs are working just fine (they have a channel Total Active Power which isn’t updated at all, but I can live with that).
The next device which works is the Bitron Video Tür-/Fensterkontakt magnetisch. To get continuous updates from that sensor, I had to set the Trust Centre Join Mode to Allow all Joins. So my question is: Is it for security reasons a better idea to not to do that? Or is there nothing to worry about?
Thanks for your replies!

(Chris Jackson) #1568

I need to take a look at the S2 devices again to remind myself. I’m not sure why remote controls are required here as if I remember correctly these devices support switches (ie the OnOff command class) so it should allow sending OnOff commands.

I can take a look at this in a week or two, but I’m travelling for a few days at the moment.

(Chris Jackson) #1569

Yes, it makes the network less secure.

(Mihail Malo) #1570

@chris Henlo.
I want to put the ConBee dongle through ser2net/socat, so that for instance deCONZ application picks it up on the other end.
Is the ConBee ttyUSB0 the same as what you use native pins for with RaspBee?
In other words, should I use a baud rate of 38400?

I put 3333:raw:0:/dev/ttyUSB0:38400 1STOPBIT 8DATABITS remctl in /etc/ser2net.conf on the server that has the USB, and successfully connected to that port with
sudo socat PTY,raw,echo=0,link=/dev/ttyUSB0 tcp: on the graphical client PC.
Should this be working?

(Chris Jackson) #1571

I don’t think this is related to the ZigBee binding is it? Firstly, the ZigBee binding doesn’t support the ConBee dongle, and secondly, deConz is a different software package that is not related to the binding.

You may be able to do what you are asking, but it might be best to ask this in a separate thread so that people who know more about this can answer as it’s not a ZigBee binding issue.

(David Masshardt) #1572

@chris, do you have an update regarding the transaction manager? Is it planed to implement this in the near future?

(Chris Jackson) #1573

Yes - this is now in the development plan and it should be available in the next month or two.

(David Masshardt) #1574

@chris, great news, thanks for the quick reply! I would like to help to test this as soon as it is ready. Is there a GitHub issue I could follow or can you send me a message when you’ve published the code?

(Chris Jackson) #1575

I don’t think there’s a GH issue on this, but I will let you know once I have something for testing. I hope early in the new year (ie it’s going to be my Christmas project :slight_smile: ).

(Berry) #1576

Since I updated to the latest 2.4.0.SNAPSHOT the switch channel is gone of my tradfri lightbulb, only got a level_control channel now? Is this intentional or did I do something wrong?

(Chris Jackson) #1577

It it intentional as it is not required - you can do everything with the level_control channel.

(Berry) #1578

I still want a switch and a dimmer for manual control of my lightbulb. If I link the level_control channel to both a switch and a dimmer item, the bulb turn on to 100% level by the switch.
The wanted behaviour is that the bulb is switched on to the last level. How should this be implemented?

(Chris Jackson) #1579

This should not be the case. If I remember correctly, when the OnOff command is sent to a level_control channel, it should send the same command as when it’s sent to the switch channel.

(Berry) #1580

I have defined the 2 items as shown below, both linked to the Levelcontrol channel:
The switch sends ON/OFF, the dimmer 0-100.
The ON command from the switch sets the lightbulb to 100% level. However, this is not represented by the dimmer item.

Switch Werkkamer_Lamp      "Werkkamer Lamp [%s]" [ "Lighting" ]    
Dimmer Werkkamer_Lamp_dim    "Werkkamer Dim [%d %%]" [ "Lighting" ]


(Chris Jackson) #1581

I checked, and you are right that different commands are used. Please raise an issue for this and I’ll have a look at it when I get a chance.

(Berry) #1582

ok no problem… where do I do this? Still very new to this, but eager to learn :slight_smile:

(Chris Jackson) #1583


Great - thanks.

(Berry) #1584

Thanks for your quick reponses, I will look into creating a ticket tonight. May I also ask you took look into another topic I have started a while ago: Zigbee binding shows wrong status

(Scott Karns) #1585

Hi, @Hamboo.

While waiting for a fix, you can achieve more or less what you are after by:

  1. Unlinking your item Werkkamer_Lamp so it becomes a proxy item of type switch
  2. … and creating two rules, one to link the commands issued to the switch proxy Werkkamer_Lamp with the dimmer item Werkkamer_Lamp_dim and a second rule to link updates to Werkkamer_Lamp_dim back to the proxy switch, Werkkamer_Lamp.
rule "Turn On/Off Werkkamer Lamp Via Proxy Switch"
    Item Werkkamer_Lamp received command
    val logID = "ProxySwitchReceivedCommand"
    logDebug(logID, "Werkkamer Lamp received command {}", receivedCommand)

    try {
    } catch (Throwable t) {
        logError(logID, "Exception in 'Turn On Werkkamer Lamp Via Proxy Switch' rule: {}", t.toString())

rule "Werkkamer Dim Updated"
    Item Werkkamer_Lamp_dim received update
    val logID = "WerkkamerDimUpdated"
    logDebug(logID, "Werkkamer_Lamp_dim received update {}", triggeringItem.state)

    try {
    } catch (Throwable t) {
        logError(logID, "Exception in 'Werkkamer Dim Updated' rule: {}", t.toString())

Disclaimer: I haven’t tested the rules I entered here, but I have implemented similar rules that are working here.