Deconz-rest-plugin: [Request Device Support] Salus Controls 'SR600' Smart Relay with input for external switch

[tannyl]

Hey. I would like to see the SR600 relay from Salus Controls get properly integrated.

• This unit is powered from 230V.
• It has a 'voltage/potential free' switching relay as output
• And it has an multifunction input for an external switch.

https://www.salus-controls.eu/products/online-control-smart-home-system/sr600-smart-relay

The function of the input can be changed to one of these:

1. No function, S1/S2 input is deactivated. (This seems to be the default)
2. Output follows input. When S1/S2 is triggered the COM/NO output is on and goes off again when S1/S2 is not triggered.
3. Input toggles output. When S1/S2 is triggered the COM/NO output toggles between on and off.
4. Input works independently of output and can be used to control other things.

My guess (and hope) is that the function of the input is based on the setting of an attribute on the SR600 itself, and not depended on using the Salus Universal Gateway.

I can connect the SR600 to my deCONZ hub (RaspBee on an Raspberry 3B+) without any problems.
It registers as a Smart Plug and the output is controllable via the REST API just fine.
The input does nothing when triggered. I guess it is set to function mode 1 by default.

I would expect the SR600 to also have some type of Sensor endpoint?

Here are all the requested images.

[ebaauw]

I would expect the SR600 to also have some type of Sensor endpoint?

Apparently not, looking at the clusters.

My guess (and hope) is that the function of the input is based on the setting of an attribute on the SR600 itself, and not depended on using the Salus Universal Gateway.

Probably an attribute in the 0xfc08 manufacturer-specific cluster. You'll need to sniff the ZigBee traffic between the Salus gateway and the switch to find out. Maybe some other (open source) integration has already figured that out (Smartthings has been useful in the past).

Input works independently of output and can be used to control other things.

Not obvious how. I would expect a client (grey) _OnOff_ cluster. Maybe that appears when the mode is set, but I haven't seen that before. Could also be some attribute reporting on 0xfc08. Again, we need to sniff the traffic to find out.

[tannyl]

I expected we needed to do some sniffing and am willing to help with this.

I tried to find a ConBee (version 1) but with no luck, so I have ordered a ConBee II. But I guess I have to wait till the Wireshark sniffer (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/405) finally supports ConBee II?

Or is there any other way I could go about sniffing the traffic we need with the ConBee II (or RaspBee for that matter)?

[ebaauw]

I think ZShark supports the RaspBee (the startup window lets you select RaspBee or ConBee), but I haven't tried it myself.

[martynwendon]

@tannyl just to state the obvious to avoid you spending money unnecessarily, but you do have the Salus Gateway, right?

[tannyl]

@martynwendon yes, I have access to a Gateway. :)

[martynwendon]

Cool :-)

Do you have any of the other Salus ZigBee devices?

They do some pretty good stuff https://salus-controls.com/uk/product-category/smart-home-range/

Unfortunately it seems that a lot of their devices use manufacturer specific clusters, I looked at the RX10RF Boiler Receiver a while ago and it doesn't support any useful clusters at all :-(

[ebaauw]

Manufacturer-specific clusters (and attributes) are very useful. However, to use them with deCONZ, we need the (technical) documentation. Unfortunately, not all manufacturers provide this. Hence the need for sniffing to reverse-engineer their working.

[tannyl]

@martynwendon I don't have any other Saulus devices yet, but if I can get this one to work, I will look into more of their devices.

[tannyl]

@ebaauw I have been playing around with the SR600 and found that it does not work in groups.
I guess it is because it does not have an group cluster?

[ebaauw]

Probably. In ZigBee, you add a group to a device, using the server (blue) _Groups_ cluster. Note that the REST API exposes it the other way around (adding a /lights resource to a /groups resource), obfuscating what happens at the ZigBee level.

Unfortunately, it's not uncommon for devices not to support groups. E.g. the Heiman smart plug doesn't. This is the kind of information I'd like to have before buying a device, but only professional-grade devices provide this level of documentation.

[mindvisionro]

Hello, also interested in this subject, i have the salus IT600.
Im trying to pair an Salus it600 - underfloor heating system( VS10WRF/VS10BRF + [KL08RF] + [CO10RF] + Gateway UGE600 - ZigBee2,4 Gh with raspbee.

[tannyl]

Status update. I got my hands on a Salus gateway and the ConBee II arrived (to take over for my RaspBee, so I can use that for sniffing). Results look good so far.
I want to test some more, because in the Salus app, you are able to group devices. I want to see how they handle that as well.

[tannyl]

@ebaauw I have some information ready now.
Cluster 0xfc08 on endpoint 9 has two attributes.

• 0x0001 (8-Bit Unsigned Integer)
  This one controls what "Input Function" should be active and can be set to the following values.
  
  
  
  • 0x00: Input is disabled (Triggering S1/S2 (connecting the terminals to each other) does nothing)
  
  
  • 0x01: Output follows input (COM/NO relay is on when S1/S2 is triggered)
  
  
  • 0x02: Input toggles output (COM/NO relay toggles between on and off each time S1/S2 is triggered)
  
  
  • 0x03: Input state can be read via attribute (Output is independent of input)
  
  
• 0x0002 (8-Bit Unsigned Integer)
  When attribute 0x0001 is set to 0x03, the state of the input (S1/S2) can be read and reported via this attribute. It will use these two values
  
  
  
  • 0x00 Input off (S1/S2 not triggered)
  
  
  • 0x01 Input on (S1/S2 triggered)
  
  

[ebaauw]

Cool. Next step is to define these in general.xml and see if you can change the settings in the deCONZ GUI.

Not sure if exposing the mode (0x0001) through the REST API has much merit (I assume you'll be setting this only once), but, if memory serves, there was a PR to set the type of input switch (rocker vs momentarily) for the ubisys switches through the API.

Does 0x0002 support attribute reporting? In that case, it might make sense to create a ZHASwitch resource for the input, in mode 0x03.

[tannyl]

I guess I'll take a look at that xml file.

I think exposing options (changing functions on devices) like this in the API is critical (or at the very least for API v2).

0x0002 does support attribute reporting by the looks of it.

Can I create this ZHASwitch via the general.xml? Or how would I go about that?

[ebaauw]

No you'd need some serious coding for that.

[tannyl]

I have added cluster and attribute to the general.xml, but sadly when deCONZ tries to read the attributes, they return "unsupported attribute".

I have compared the read attributes frame from the Salus Gateway and deCONZ.

I have underlined the differences.

Could it be because the Frame Control Fields are different, or maybe the fact that the Salus Gateway also sends the manufacturer code along with the read request.

Side note: The Salus Gateway asks about 4 attributes, but the SR600 reports "unsupported" to 0x0003 and 0x0004.

[ebaauw]

You need to add the manufacturer code to the xml definition of the cluster and of each attribute.

[tannyl]

This is what I have so far:

<!-- Salus Controls / Computime -->
<cluster id="0xfc08" name="Salus/Computime" mfcode="0x1078">
    <description>Salus/Computime manufacturer-specific cluster.</description>
    <server>
        <attribute-set id="0x0001" description="Input Control">
            <attribute id="0x0001" name="Input Function" type="u8" default="0x00" access="rw" required="m"  mfcode="0x1078">
                <description>Changes how the input functions on the SR600. Possible options are:
0: Input is disabled. Triggering it does nothing. State of input can not be read via the 0x0002 attribute.
1: Input controls the state of the output. The output will always be the same state as the input, and can not be controlled from the on/off cluster.
2: Input toggles the sate of the output each time the input goes from triggered to not triggered. Output is also controllable via the on/off cluster.
3: Input is independent of the output, and the state of the input can be read from the 0x002 attribute.</description>
                <value name="0: Input is disabled" value="0x00"></value>
                <value name="1: Input controls output (output follows input state)" value="0x01"></value>
                <value name="2: Input toggles output state" value="0x02"></value>
                <value name="3: Input is independent (state via att. reporting)" value="0x03"></value>
            </attribute>
            <attribute id="0x0002" name="Input State" type="u8" default="0x00" access="r" required="m"  mfcode="0x1078">
                <description>When attribute 0x0001 is set to 3, the state of the input (triggered or not triggered) can be read via this attribute.</description>
                <value name="On" value="0x01"></value>
                <value name="Off" value="0x00"></value>
            </attribute>
        </attribute-set>
    </server>
    <client>
    </client>
</cluster>

What is working:

• The two attributes can be read one at a time, and writing to 0x0001 works as well. The function of the input changes as expected.

What is NOT working:

• Reading all attributes at the same time fails with the error "unsupported attribute"
  
  If I compare the data frames, it again seems to be missing the manufacturer code in the deCONZ request (right) compared to the Salus Gateway request (left).
  
• I haven't gotten attribute reporting to work yet, mostly because I don't know exactly what turns it on. I guess you have to do a bind?

Questions:

• For it all to work, I have to use the correct data types u8, but it would be nice to have the options show up as an enum8. Is there some way to still use the u8 but have it show up with a dropdown box with the values I have setup in the XML?
• Considering that the group cluster is missing from the SR600, could a "missing group cluster" workaround be implemented? So when deCONZ sees the group broadcast, it sends unicast to the group members that lack the group cluster.

[ebaauw]

The two attributes can be read one at a time, and writing to 0x0001 works as well. The function of the input changes as expected.

So deCONZ is sending the manufacturer code when reading/writing the attributes individually, ...

Reading all attributes at the same time fails with the error "unsupported attribute"

... but not when reading all attributes?! I haven't seen this before.

I haven't gotten attribute reporting to work yet, mostly because I don't know exactly what turns it on. I guess you have to do a bind?

Yes, from the server (blue) 0xfc08 cluster on the relay to the first endpoint of the coordinator. Next, you need to configure attribute reporting on the attribute(s) (in the popup window you used to write the attribute).

For it all to work, I have to use the correct data types u8, but it would be nice to have the options show up as an enum8. Is there some way to still use the u8 but have it show up with a dropdown box with the values I have setup in the XML?

No, you'd need to get Salus to define the attribute as enum8. I'm not sure whether deCONZ likes the value tags for an u8 attribute. Could it be the reason why it doesn't use the manufacturer code when reading all attributes?

Considering that the group cluster is missing from the SR600, could a "missing group cluster" workaround be implemented? So when deCONZ sees the group broadcast, it sends unicast to the group members that lack the group cluster.

I'd say: no, way too complicated. How would you generate the group broadcast? If it's from deCONZ rules, you could add additional actions for the /lights resources to generate unicast commands. If it's from wireless switches, you could try and add an additional binding from the switch's client (grey) _OnOff_ cluster to the relay. I'm afraid not all wireless switches support multiple bindings, though.

[tannyl]

So deCONZ is sending the manufacturer code when reading/writing the attributes individually, ...
... but not when reading all attributes?! I haven't seen this before.

Correct. Any way to add the manufacturer code to the "read all" command from the XML?

Yes, from the server (blue) 0xfc08 cluster on the relay to the first endpoint of the coordinator. Next, you need to configure attribute reporting on the attribute(s) (in the popup window you used to write the attribute).

Adding the bind worked as it should, and when 0x0001 is set to 0x03, it starts reporting the changes for 0x0002 right away. I don't even have to configure any attribute reporting settings.
If read the attribute reporting settings to begin with it just responds with "not found". If I enter some new settings, it will remember them, and report them back when I try to read them. But as said, it does not seem to matter that I add these settings or remove them again.

No, you'd need to get Salus to define the attribute as enum8. I'm not sure whether deCONZ likes the value tags for an u8 attribute. Could it be the reason why it doesn't use the manufacturer code when reading all attributes?

I tried removing the values for the attributes, but it does not make any difference. Still reports "unsupported attribute" for each of them when reading all at the same time.

I don't think I am going to get Salus to change the attribute. :)

I was thinking that Dresden Elektronik could add an option to showas (along side the 3 hex, bin and slider) that made it show up as an dropdown with the defined values.

[tannyl]

So now what?

How do we get the "read all" to work.
How do we get the input state to show up as a useable state in the REST API.

[tannyl]

The above questions are stil waiting..

[Mimiix]

@ebaauw Can you elaborate on this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.