Zigbee binding

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.

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!

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.

Yes, it makes the network less secure.

@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:10.22.22.2:3333 on the graphical client PC.
Should this be working?

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.

1 Like

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

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

1 Like

@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?

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: ).

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?

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

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?

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.

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" ]

image

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.

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

Here.

Great - thanks.

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

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"
when
    Item Werkkamer_Lamp received command
then
    val logID = "ProxySwitchReceivedCommand"
    logDebug(logID, "Werkkamer Lamp received command {}", receivedCommand)

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

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

    try {
        Werkkamer_Lamp.postUpdate(triggeringItem.getStateAs(OnOffType))
    } catch (Throwable t) {
        logError(logID, "Exception in 'Werkkamer Dim Updated' rule: {}", t.toString())
    }
end

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