Heimann Smart remote Control HS1RC sends 4 events on single click

[olix74]

Describe the bug

Hello, first of all thank you very much for the initial support for the Heiman HS1RC remote!
I'm currently facing the issue that a single button press on the remote creates 4 events - arriving at 8-10s intervalls.
Please se attached log file.

Steps to reproduce the behavior

reproducable with every press of every button.

Expected behavior

just one event

Screenshots

N.A.

Environment

• Host system: Raspberry Pi3
• Running method: Raspbian/PiOS
• Firmware version: (26580700)
• deCONZ version: (2.05.79)
• Device: ConBee II
• Do you use an USB extension cable: no

deCONZ Logs

18:09:49:122 APS-DATA.indication srcAddr: 0x76a0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0501, lqi: 135, rssi: -77
18:09:49:123 button 3002 Emergency
18:09:57:133 APS-DATA.indication srcAddr: 0x76a0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0501, lqi: 151, rssi: -75
18:09:57:134 button 3002 Emergency
18:10:05:150 APS-DATA.indication srcAddr: 0x76a0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0501, lqi: 151, rssi: -75
18:10:05:150 button 3002 Emergency
18:10:15:239 APS-DATA.indication srcAddr: 0x76a0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0501, lqi: 143, rssi: -76
18:10:15:240 button 3002 Emergency

Additional context

N.A.

[ebaauw]

Can you sniff the Zigbee traffic and see if those messages have different sequence numbers? Also, can you see of the remote receives an ACK on these messages?

I don’t know this remote, but my first hunch would be that the remote resends the command when it doesn’t receive an ACK. 8 to 10 seconds seems to be too long for network hiccups. And retries seem appropriate for an IAS controller. How big is your network? Have you experienced routing issues (unreachable devices) before?

[cllatser]

Hi. I'm the one who asked for integration. From the beginning, I realized that I was sending the event 4 times, but I thought what was normal. I have solved it with a rule in Node-Red that ignores the other three. But it would be nice if you only sent one event.

[olix74]

I would also asume the remote is missing an ACK. Regrettably I don't know how to sniff the Zigbee messages. Can you provide a little instruction how to do that?
Thank you,
Oliver

[ebaauw]

I use ZShark for Zigbee sniffing, see #405. You need a second RaspBee or ConBee for that (the original versions, not the II).

[cllatser]

Good night, how you notice. Until a day ago. When I pressed a button on the remote, the light came on red and then green. Yesterday I found the Deconz Addon stopped and started again. Only the red light comes on, but sends the event.

[olix74]

Hello ebaauw,
I will follow up with ZShark - but since I need to order Conbee/Raspbee it will take some time. In parallel: if we assume the device is not receiving an ACK, what could/would we do? Is deconz supposed to send an ACK anyway/ is ACK implemented?
Thank you,Oliver

[ebaauw]

Honestly, I don’t know. Need some more insight into what’s happening. If the switch resends the same message, with the same sequence number, then deCONZ should recognise that it already processed this message. If it’s a different sequence number, deCONZ cannot tell it apart from another press. The remote is intended to control an IAS system. I think @SwoopX had to advertise the 0x0501 cluster on the coordinator to get it to work. They’re likely to work differently from your standard consumer-grade light controllers. Maybe we need to implement some response from that cluster.

[SwoopX]

This device here is the newer version of the one I had in hands. I indeed required exposure of IAS ACE server cluster to be working at all since it sends a match descriptor request which otherwise remains unanswered, resulting in an immediate leave.

The older version definitively has send only one command and was fine with it as I recall. We'd indeed require a network sniff go gain more insights on what's happening here. Could very well be that the device expects the corresponding IAS zone responses, as @ebaauw mentioned.

An option for that could be that you compile an experimental version of the REST API plugin, which can log the zigbee traffic. It would require a bare OS running deconz, so no HA, docker or other stuff in between.

Lastly, pease note that those kind of devices were meant to stear/control security systems originally and not meant to be used as "regular remotes".

[olix74]

Hello @SwoopX and @ebaauw,
firts of all thank you again very much for all your support!
I have some problems finding Conbee 1 or raspbee 1 so I guess I cannot use ZShark.

I'm also really no expert in Zigbee. Nevertheless I had a look at https://zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06-zigbee-cluster-library-specification.pdf which I assume to be part of the relevant zigbee spec.
I would agree to @SwoopX that the Heiman is expecting responses from a real security system. Nevertheless I assume many deconz users want to use it as a 4 button general control - so it would be fine to "pretend" to be such a security system.
Here is my proposal for that after reading through the spec:

8.3 specifies IAS ACE,
8.3.2.4 the Commands Received (from Heiman remote )and
8.3.2.5 the expected/proposed responses to be generated (by deconz).

Proposal 1:
I assume that button 1002,2002 and 4002 generate an "Arm Command" according to 8.3.2.4.1
As such they probably expect a response according to 8.3.2.4.1.5
Here it says "The device SHALL generate an "Arm Response command" (see 8.3.2.5.1)to indicate the resulting armed state."
8.3.2.5.1 explains this response.
Respone should be two bytes and is explained below:
Command ID --> 0x00 Arm Response
followed by following "Arm Notification" (enum8) content according to following table
Button 1002 --> 0x01 Only Day/Home Zones Armed
Button 2002 --> 0x00 All Zones Disarmed
Button 4002 --> 0x03 All Zones Armed

Proposal 2:
In addition it MIGHT be necessary to send "Panel Status Changed Command" ID=0x04 according to 8.3.2.5.5
I would assume following responses
Button 1002 -->
Panel Status: 0x01 Armed Stay, Seconds Remaining: 0x00, Audible Notification: 0x01 (default), Alarm Status: 0x00 (no Alarm)
Button 2002 -->
Panel Status: 0x00 Panel disarmed, Seconds Remaining: 0x00, Audible Notification: 0x01 (default), Alarm Status: 0x00 (no Alarm)
Button 4002 -->
Panel Status: 0x03 Armed away, Seconds Remaining: 0x00, Audible Notification: 0x01 (default), Alarm Status: 0x00 (no Alarm)

Proposal 3:
Regrettably 8.3.2.4.3 does not explain the response to emergency button 3002.
I would propose to also send a "Panel Status Changed Command" ID=0x04 according to 8.3.2.5.5
Button 3002 -->
Panel Status: 0x07 In alarm, Seconds Remaining: 0x00, Audible Notification: 0x01 (default), Alarm Status: 0x03 (Emergency)

Maybe this does sufficiently mimic an alarm/ security system for the remote to stop sending repeats.
What do you think? Is it worth a try without further log files?
I used to be a programmer - nevertheless, likely I'm a bit out of practice. I could support if directed to the right files or I could offer to test. I would also sponsor or send a Heiman remote to you.
Thank you again,
Oliver

[SwoopX]

You can give it a go, if you want

git clone --branch dev_debug https://github.com/SwoopX/deconz-rest-plugin.git

When you start deconz, don't do it via systemd, but call it directly /usr/bin/deCONZ --dbg-info=2 --dbg-error=2 > debug

The steps to compile the plugin are explained in the readme fo this repo. Make sure to first make a backup of your original plugin! The code version is based on yesterdays beta release.

[ebaauw]

I would first check the sequence numbers. Ignoring a repeated message is way less work.

[olix74]

Hello @ebaauw and @SwoopX ,
I would agree to @ebaauw and would try that first. What is the expected behaviour of the already implemented sequence number check? Would it discard the repeated messages already or would that be a new feature? Thank you, Oliver

[ebaauw]

Had a similar issue for the IKEA SYMFONISK controller. I simply don't set a new buttonevent value when the same sequence number is received.

I added a previousSequenceNumber property to Sensor to remember the last sequence number. And then added a simple check in checkSensorButtonEvent():

deconz-rest-plugin/de_web_plugin.cpp

Lines 3474 to 3482 in f245b37

	else if (sensor->modelId().startsWith(QLatin1String("SYMFONISK")))
	{
	if (zclFrame.sequenceNumber() == sensor->previousSequenceNumber)
	{
	return;
	}
	sensor->previousSequenceNumber = zclFrame.sequenceNumber();
	checkReporting = true;
	}

In theory, this could cause an issue when the next button action happens exactly when the device has revolved the sequence numbers (i.e. the other sequence numbers are used by messages that don't trigger checkSensorButtonEvent()). I don't think that's very likely to happen, and worse case, you need to press the button again. A more structural solution would be in APIv2, where all messages by a device are handled by one function, which thus would see all sequence numbers.

[olix74]

Thanks a lot, I will give that try -would be an easy fix. But I will do that later this week.
Best regards,
Oliver

[cllatser]

Good afternoon. It's been a few days, that when I press the disarm button, the green confirmation led immediately lights up. But it only does it with the disarm button. 🧐

[stale]

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[stale]

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.

[SwoopX]

I guess I know what's the issue here. Received another keyfob today from a different vendor and sniffed the traffic. It also repeats the commands...

I guess I know what to do but it may take some time.