Honeywell smoke detector (Xiaomi JTYJ-GD-01LM/BW) selftest fails with "No network route"

[guardiande]

Bug Report

What happened

Redoing my whole setup I just recently paired the Honeywell smoke detector. I was paired directly to the CC2531 coordinator. To make sure the device works I pressed the button on the detector and Z2M received a normal payload message.

Then I decided it would be good to do a self test. That failed with the following error:

error 2020-09-06 12:41:00: Publish 'set' 'selftest' to 'SmokeDetector1' failed: 'Error: Write 0x00158d000215e015/1 ssIasZone({"65521":{"value":50397184,"type":35}}, {"timeout":35000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null}) failed (Data request failed with error: 'No network route' (205))'
info  2020-09-06 12:41:00: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'selftest' to 'SmokeDetector1' failed: 'Error: Write 0x00158d000215e015/1 ssIasZone({\"65521\":{\"value\":50397184,\"type\":35}}, {\"timeout\":35000,\"disableResponse\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null}) failed (Data request failed with error: 'No network route' (205))'","meta":{"friendly_name":"SmokeDetector1"},"type":"zigbee_publish_error"}'

I read the other issues on the similar problems but they all refer to the device being connected to a router.

I once again had problems with pairing the device (see #4271). I had to resort to the secondary device and resetting the adapter configuration. This time I was not able to finish the interview sucessfully. I fixed the database to say interview successful true and the device seems to work with the exception of the selftest.

What did you expect to happen

To hear a beep of the device after performing the selftest.

How to reproduce it (minimal and precise)

See above.

Debug Info

Zigbee2MQTT version: 1.14.4
Adapter hardware: CC2531
Adapter firmware version: 20190619

[Sandriekus]

Have the exact same issue after upgrading to 1.14.4.
Restored a backup to 1.14.3 and everything is working correct!
I'm using the slaesh stick

[Koenkk]

@guardiande would you be able to sniff the traffic when you execute the command? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

@Sandriekus are you able to post the herdsman debug logging of this error on 1.14.4?

To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging

[Enzokot]

@Koenkk can I help? I'm using the cc2538 stick

[Koenkk]

@Enzokot yes please sniff the traffic like suggested in: #4285 (comment)

[Enzokot]

@Koenkk herdsman debug log?

[Koenkk]

see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging

[Enzokot]

@Koenkk
0x00158d00039d9398 - without router
0x00158d0003943639 - with router
log.txt

[Koenkk]

@Enzokot are you also able to provide a sniff? (https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html)

[Enzokot]

@Enzokot are you also able to provide a sniff? (https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html)

Yep, but later. Need to find one more stick

[Enzokot]

@Koenkk sniff synchro with herdsman? at the same time?

[Koenkk]

Preferably both.

[Enzokot]

Preferably both.

Done
0x00158d00039d9398 - without router
0x00158d0003943639 - with router
logs.zip

[Sandriekus]

sorry for the late response.
i can test also if you want.

current setup:
Zigbee2MQTT version: 1.14.4.1
Adapter hardware: slaesh’s CC2652RB stick
Adapter firmware version: CC2652RB_20200805

when performing a self-test to the HoneyWell Smoke detector:

Zigbee2MQTT:error 2020-09-19 09:04:35: Publish 'set' 'selftest' to '0x00158d00052b7f72' failed: 'Error: Write 0x00158d00052b7f72/1 ssIasZone({"65521":{"value":50397184,"type":35}}, {"timeout":35000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null}) failed (Data request failed with error: 'No network route' (205))'

Zigbee2MQTT:info  2020-09-19 09:04:35: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'selftest' to '0x00158d00052b7f72' failed: 'Error: Write 0x00158d00052b7f72/1 ssIasZone({\"65521\":{\"value\":50397184,\"type\":35}}, {\"timeout\":35000,\"disableResponse\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null}) failed (Data request failed with error: 'No network route' (205))'","meta":{"friendly_name":"0x00158d00052b7f72"},"type":"zigbee_publish_error"}'

i can also upgrade the adapter firmware to the latest dev for testing if you want.
and i have installed the zigbee map addin, here i see my 5 honeywell smoke detectors showing up without routes.

[Sandriekus]

@Koenkk
i've enabled herdsman debug on my current config and performed a selftest to one of the Smoke Detectors.

Zigbee2MQTT version: 1.14.4.1
Adapter hardware: slaesh’s CC2652RB stick
Adapter firmware version: CC2652RB_20200805
log.txt

[Enzokot]

@Koenkk
Sensitivity doesn't work too when the device connected to a router

[Sandriekus]

ok, so for testing i've updated the firmware on the slaesh's CC2652RB to the latest dev version:

current setup:
Zigbee2MQTT version: 1.14.4.1
Adapter hardware: slaesh’s CC2652RB stick
Adapter firmware version: CC2652RB_20200830

herdsman debug logging when performing a self-test to the HoneyWell Smoke detector:
log.txt

[Sandriekus]

@Koenkk
Sensitivity doesn't work too when the device connected to a router

i can confirm that:
log.txt

[Koenkk]

I've did a lot of investigation in the smoke sensor lately and found out that many routers cannot handle this device (including our zstack coordinator). This is because the poll rate is very slow, causing commands to fail very often.

I expect pairing this device to a Xiaomi router (e.g. xiaomi plug) should solve this. The smoke sensor does not switch parents once it's paired so it should also keep working. You can check the parent via the networkmap: https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgenetworkmap

[Sandriekus]

@Koenkk Was there a major change in versions between 1.14.3 and 1.14.4?
Because with version 1.14.3 everything was working perfectly

[Enzokot]

@Koenkk

0x00158d00039a8358 - works great
0x00158d0003943639 - doesn't work selt-test and sensitivity (please, look at connections arrow. coordinator + router)

[Sandriekus]

On my map i see some smoke detectors with routes, and some without routes:

the 0x00158d000528c65b (with routes) self test is working
the 0x00158d00054263de (without routes) self test is trowing the error

[Koenkk]

@Sandriekus yes there was some change. Can you try this fw:
znp_CC2652RB_LAUNCHXL_tirtos_ccs.hex.zip
and repair the device (confirm that the device has a route now directly to the coordinator) and selftest again?

[Sandriekus]

@Koenkk

i've installed the firmware you've mentioned.
re-paired the 0x00158d00054263de honeywell smoke detector
performed a self-test.. and this is succesfull!

i've checked the routes, the device is not directly connected to the coordinator, but it is working!
see log:
log.txt

[Koenkk]

can you also check if it works when connected directly to the coordinator? Because when connected through the router the fw update shoulnt be necessary.

Try repairing it close to the coordinator.

[Sandriekus]

can you also check if it works when connected directly to the coordinator? Because when connected through the router the fw update shoulnt be necessary.

Try repairing it close to the coordinator.

Sure! Going to try tomorrow morning and let you know

[Sandriekus]

@Koenkk
re-paired the smoke sensor directly to the coordinator. performed a self-test and this is working.
i've checked the zigbee map addon and the smoke sensor is directly connected.

herdsman debug log:
log.txt

So i saw in my zigbee map addon that there was one other smoke detector without routes (0x00158d00052b7f72)
re-paired the smoke sensor directly to the coordinator but it doenst give me a link to in the zigbee addon
herdsman debug log is showing the "no network route 205 error while paring"

herdsman debug log:
log.txt

[Koenkk]

@Sandriekus have you tried to force remove it first before pairing? https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgeconfigremove

[Sandriekus]

@Koenkk i have force removed the device, removed the battery for couple of minutes and then re-paired:

2020-09-20T16:43:26.985Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0x00158d00052b7f72:48962,205,5)
2020-09-20T16:43:26.987Z zigbee-herdsman:controller:endpoint Read 0x00158d00052b7f72/1 ssIasZone(["iasCieAddr","zoneState"], {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Data request failed with error: 'No network route' (205))
2020-09-20T16:43:26.990Z zigbee-herdsman:controller:device:log Interview procedure failed but got modelID matching 'lumi..*', assuming interview succeeded
2020-09-20T16:43:26.998Z zigbee-herdsman:controller:device:log Interview - completed for device '0x00158d00052b7f72' because of quirks ('Error: Read 0x00158d00052b7f72/1 ssIasZone(["iasCieAddr","zoneState"], {"timeout":10000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Data request failed with error: 'No network route' (205))')
2020-09-20T16:43:27.004Z zigbee-herdsman:controller:log Succesfully interviewed '0x00158d00052b7f72'
Zigbee2MQTT:info  2020-09-20 18:43:27: Successfully interviewed '0x00158d00052b7f72', device has successfully been paired
Zigbee2MQTT:info  2020-09-20 18:43:27: Device '0x00158d00052b7f72' is supported, identified as: Xiaomi MiJia Honeywell smoke detector (JTYJ-GD-01LM/BW)
Zigbee2MQTT:info  2020-09-20 18:43:27: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_successful","meta":{"description":"MiJia Honeywell smoke detector","friendly_name":"0x00158d00052b7f72","model":"JTYJ-GD-01LM/BW","supported":true,"vendor":"Xiaomi"},"type":"pairing"}

see full log here:
log.txt

also setting the sensitivity doesn't work:

Zigbee2MQTT:debug 2020-09-20 18:48:11: Received MQTT message on 'zigbee2mqtt/0x00158d00052b7f72/set' with data '{"sensitivity": "medium"}'
Zigbee2MQTT:debug 2020-09-20 18:48:11: Publishing 'set' 'sensitivity' to '0x00158d00052b7f72'
Zigbee2MQTT:error 2020-09-20 18:48:36: Publish 'set' 'sensitivity' to '0x00158d00052b7f72' failed: 'Error: Write 0x00158d00052b7f72/1 ssIasZone({"65521":{"value":67239936,"type":35}}, {"timeout":35000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null}) failed (Data request failed with error: 'No network route' (205))'
Zigbee2MQTT:debug 2020-09-20 18:48:36: Error: Write 0x00158d00052b7f72/1 ssIasZone({"65521":{"value":67239936,"type":35}}, {"timeout":35000,"disableResponse":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null}) failed (Data request failed with error: 'No network route' (205))
    at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:311:27)
    at Generator.next (<anonymous>)
    at fulfilled (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:24:58)
Zigbee2MQTT:info  2020-09-20 18:48:36: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'sensitivity' to '0x00158d00052b7f72' failed: 'Error: Write 0x00158d00052b7f72/1 ssIasZone({\"65521\":{\"value\":67239936,\"type\":35}}, {\"timeout\":35000,\"disableResponse\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null}) failed (Data request failed with error: 'No network route' (205))'","meta":{"friendly_name":"0x00158d00052b7f72"},"type":"zigbee_publish_error"}'

[Koenkk]

Hmm, seems it still doesn't work indeed.

I would recommend pairing the smoke sensor to a router instead.

[Sandriekus]

Hmm, seems it still doesn't work indeed.

I would recommend pairing the smoke sensor to a router instead.

an IKEA LED1842G3 bulb is oke for router?

[Sandriekus]

@Koenkk that is correct.
with that specific firmware on my slaesh’s CC2652RB stick and zigbee2mqtt version 1.14.4.1 i can confirm the following is working:

• pairing the smoke sensors
• set sensitivity
• perform self-tests
• zigbee map addon shows routes

it is running stable now for 2 days (also after restarts of HA or complete host)

i can upgrade Zigbee2mqtt to 1.14.4.2 if you want me testing that version with the znp_CC2652RB_LAUNCHXL_tirtos_ccs.hex.zip firmware?

[Koenkk]

@Sandriekus thanks, published the firmware: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

[pedroke]

Hi guys, I already created the duplicate of this issue which has been closed #4502
After finding this discussion I applied the proposed solution:

1. I updated the firmware of my ZZH to CC26X2R1_20200925.zip
2. I force removed the xiaomi honeywell smoke detector from zigbee2mqtt
3. Removed batteries and pressed the button to discharge
4. Disconnected my router (ImmaxNeo socket) so that it doesn't mess things.
5. Smoke detector paired again with the network.

Note: I didn't update zigbee2mqtt, I'm still on the latest official release 1.14.4, should I switch on dev?

But the issue is still present even after those steps. Firmware is new for sure and it is still not possible to send messages to smoke detector and it still appears detached in the network map. Although reports correctly.

One thing I noticed after re-flashing of the firmware of ZZH. All devices seemed to be working but all were displayed as detached in the network map. I needed to press the join button on each of them to be displayed correctly again. Even though no routers were involved. After re-joining they are displayed correctly on the map except for Sonoff humidity temperature and Xiaomi Smoke..
Strange..
I have to find how exactly is this "ping" working in Zigbee networks, since almost all of my devices are battery-powered, only turning on when they report so theoretically they should also NOT respond to any kind of ping..

UPDATE: Additionally to my findings above, since I have the new firmware I'm experiencing unavailability of random sensors. I'm not sure if it is related, but I'm switching back to 20200805 :(

[pedroke]

One additional remark from my side. Do I understand correctly that "ping" is implemented internally as "node descriptor request".. If so, then it is really strange how it should work for sleeping devices. If I understand the specification correctly it advises to cache node descriptors on coordinators and routers but it consumes memory.. so probably there is some limitation. It would mean, that may be in practice only a limited number of descriptors is cached and it may result in unsuccessful "pings" for sleeping devices and it cannot be solved only by changing the timeouts.. Does anybody know how many node descriptors are cached by particular firmwares? If we cannot change this, then the whole network map and pinging do not make much sense for larger networks. But the impossibility to send the message e.g. to smoke sensor is a different question and might be related to timeouts if I understand correctly.

[Koenkk]

@pedroke to check whether the issue is present, use 20200925 in combination with Zigbee2MQTT 1.15.0.

What do you exactly mean with ping? If you mean availability you can read here how it works for EndDevices: https://www.zigbee2mqtt.io/information/availability.html#non-pingable-devices

[pedroke]

@Koenkk Thanks for the hint, I will try with the newer version.

By "ping" I mean the mechanism of how a network map is built. What I can't understand is that when I trigger the network map build, all my battery-powered devices, which are sleeping for sure are displayed as connected. So it is probably only decided based on the received messages in the last 24 hours - as you mentioned. But e.g. smoke detector which is also SED is displayed as detached, although messages come regularly.. so I suppose that for that specific device different approach is taken. And what is even more interesting, that even Sonoff humidity and temperature which is almost the same as Aqara temperature sensor is also sometimes displayed as detached, even though it reports periodically...
So.. that was my confusion. whether ping is executed by "node descriptor request" or simply by the last 24 hours message or by any other approach and what are the rules and exceptions there.. And when I think about the "No route" error, it is even more interesting, why is it so. When the sensor joins the network directly to the coordinator, how is it possible that there is no route defined to it? I can understand that the message timeout can be a problem for a partially sleeping device, but a missing route? Hmm?
All in all, it is not that important, but one has to think about it when it's happening... :)

[Koenkk]

@pedroke the way this works is that not the end device itself, but the parent of the end device (a router) report what childs it has, this is what you see on the network map.

[pedroke]

Let's take an example. I reflashed firmware on ZZH..All devices were reporting correctly and had strong signal. But on the map all devices which are reporting to coordinator were detached. So coordinator was accepting messages from them, it was aware of them and still was not able to name them for networm map... strange. As soon as any of the device forcibly re-joined, it was again showing attachment in the map. Even stranger is that devices behind router were displayed correctly.
So.. something that was held in the memory of coordinator was deleted during flashing and resulted in detached nodes in the map. Since router was not flashed it preserved the list of its children.
So the question is, based on what parent returns the list of children?

[pedroke]

Ok..now I see.I checked the code of network map so the connections are based on routing table of the device. So in case there are detached devices there is no route defined. That also explains why smoke detector returns 'no route' error while it is detached in the map. And it also explains that flashing clears the map from RAM. But why are some routes cleared during runtime remains mistery for me. ED like xiaomi battery sensors keep the connection on map for ages even though they sleep and not listen at all..but e.g. smoke detector keep detaching and also e.g Sonoff temperature which is basically very similar to aqara...I need to find out what are the rules for routing table. What kicks some records out of it and why some of the sleepy devices remain untouched without any problem.

[Anjerlaan]

Hi @Koenkk,

You mentioned also a new firmware along with the Z2M update
#4832 (comment)
I just saw you have created a new firmware for the ZZH adapter

https://electrolama.com/projects/zig-a-zig-ah/#flash-firmware
I am doing this for the first time, so I have some additonal questions about new firmware flashing:

• Do I first have to flash the new ZZH Firmware and then update Z2M, or the other way around?
• Do I need to to be in bootloader mode to flash the new firmware
• Do I need to erase the old flash first
• Do I have to change the Pan-ID
• Do I need to repair all devices after the new flash

Greetzzz,

Gerben

[Koenkk]

• Doesn't matter
• yes
• Just run the command here: https://electrolama.com/projects/zig-a-zig-ah/#flash-firmware (this will also erase)
• No
• No

Just released version Zigbee2MQTT 1.16.0 so make sure to use that.

[andrej-peterka]

Hey @Koenkk ,

don't want to steal the conversation, but I noticed I also have a "No network route" error with a SilverCrest Motion sensor when pairing to zzh with the latest firmware.

I created a forum post here:
https://zigbee2mqtt.discourse.group/t/problem-pairing-to-zzh-working-with-cc2531/1773

And here's the relevant log file when pairing that device fails:
https://hastebin.com/ojimimozek.apache

Search for "No network route".

Not sure if related, just though worth pointing it out.

[pedroke]

@andrej-peterka For me it seems more like a failed interview - many 240 errors.. and subsequent removal from network and thus no route is found anymore. Have you tried to pair closer to the coordinator? Btw didn't you press pairing button while the interview was still in progress aprox after 17 seconds? Maybe Koen have better understanding, from the logs it seems to me like unfinished interview and device leaving the network.

[andrej-peterka]

@pedroke I paired it right next to the coordinator and did not touch anything. Maybe some motion triggered something, not sure.
But yeah, I saw the "left the network" messages also, no idea what caused them, I assumed a failed interview.

I'm a newbie when it comes to the zigbee network, so my knowledge is lacking in this regard, sorry. Seems I jumped to conclusion too fast.

[pedroke]

@andrej-peterka As it turned out with Honeywell smoke detector, the problem was with enrolling it to IAS zone. It is a special feature of zigbee specification for some security sensors.. in the end we found that coordinator was not triggering the enroll procedure in a way that sensor expected.. and it was fixed. But there were logs about enrolling.. In your case I see some data confirmation errors code 240 which is "transaction expired" that's why I thought that interview failed because of weak signal..but now..I don't know.. Btw..good to know that Lidl is also in Zigbee business ;)

[Anjerlaan]

I had the same difficulty with pairing by just holding it close to my ZZH adapter.
But with the domoticz-zigbee2mqtt-plugin the smoke detector was paired quite fast actually.

[Anjerlaan]

@Koenkk
As you advised I have updated the ZZH adapter to Z-Stack_3.x.0 20201026 firmware and zigbee2mqtt to 1.16.2.

Result was that 2 of the 3 JTYJ-GD-01LM/BW smoke alarm devices suddenly had no network route.
All 3 were paired when I still had my previous 2531 adapter in the old firmware 1.15 version.
The 3rd smoke alarm, which was paired to a 2530 router was still on the network after the Update to ZZH and 1.15 and also 1.16.2.
So I had to force remove (no other option was possible) those 2.
When I paired them again with the new firmware and Z2M version, (with Z2M paring was a problem, but with domoticz Z2M plug-in I was able to pair them successfully), both Smoke detectors report in the experimental front end no LQI value: no converter is available according to the message in frontend.

This the log after restart Z2M...totally different values then the 3rd “Rookmelder_zolder”.
I also have tried to pair one of the 2 “Rookmelder_boven” to the 2530 router but also with the same result.
So it looks like the new firmware and Z2M is not solving the pairing issue

info  2020-11-21 17:03:33: MQTT publish: topic 'zigbee2mqtt/Rookmelder_boven', payload '{"ac_status":false,"battery":100,"battery_low":false,"enrolled":false,"restore_reports":false,"smoke":false,"smoke_density":1,"supervision_reports":false,"tamper":false,"trouble":false,"voltage":3085}'
info  2020-11-21 17:03:33: MQTT publish: topic 'zigbee2mqtt/Rookmelder_beneden', payload '{"ac_status":false,"battery":100,"battery_low":false,"enrolled":false,"restore_reports":false,"sensitivity":"low","smoke":false,"smoke_density":1,"supervision_reports":false,"tamper":false,"trouble":false,"voltage":3075}'
info  2020-11-21 17:03:33: MQTT publish: topic 'zigbee2mqtt/Rookmelder_zolder', payload '{"battery":100,"linkquality":75,"sensitivity":"medium","smoke":false,"smoke_density":1,"voltage":3085}'

Update: the Smoke alarm which I have paired now with the 2530 router now has an LQI

[pedroke]

@Anjerlaan I had also problems after update. On Koen's suggestion I deleted coordinator backup BEFORE I plugged freshly flashed ZZH and that helped. Obviously the ZZH NVRAM included zigbee related variables such as indirect message timeout and thus even with the new firmware old values were restored from backup.

[Anjerlaan]

@Anjerlaan I had also problems after update. On Koen's suggestion I deleted coordinator backup BEFORE I plugged freshly flashed ZZH and that helped. Obviously the ZZH NVRAM included zigbee related variables such as indirect message timeout and thus even with the new firmware old values were restored from backup.

@pedroke So let met get it straight:

1. Force remove 3 smoke alarms from network.
2. Stop Zigbee2mqtt
3. Unplug ZZH
4. Delete in data directory: coordinator_backup.json
5. Plug in ZZH in flash mode (press button while plugging in)
6. Reinstall (overwrite) latest ZZH firmware
7. Start Zigbee2mqtt
8. Pair smoke alarms to either ZZH or 2530 Router

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days