Heiman Smoke Sensor - no state updates - after upgrade from stable deconz 2.12 --> 2.21.2

deCONZ General Support
1

I upgraded my deCONZ version from deCONZ stable 2.12 to stable 2.21.2.
Firmware of ConBeeII was upgraded to version 26780700.

My zigbee network has about 63 nodes with nodes/plugs from Ledvance/Osram, Innr, Nous, Ikea, Heiman
and with several endpoints: Aqara sensors, Eurotronic ZigBee Spirit, Tradfri Motion sensors - all working excellent with the new versions!!!

Describe the bug

I start deCONZ gui-mode and can see deconz establishing drawn connections to all of my devices at startup - even to all of my smoke sensors with all states (battery,state,reachable,…) are getting updated once.

I have got a total of 15 Heiman smoke sensors in 3 groups of clones with different Problems:

7 Schwaiger ZHS20 (Heiman HS1SA-M - Model Identifier: SMOK_YDLV10 DateCode: 20150330)
==> Are all getting state updates in between 3-10 hours! BUT: Phoscon shows a few of them as "not reachable" although they were updated successfully before.

3 Orvibio SF21 smoke sensor swversion 1.1.1
==> Are reachable on deconz startup with all states getting updated, but after that, they never get updated again.
I can see the sensors talking to deconz from time to time - blue dot blinking. But no refreshing of the states.

5 Heiman SmokeSensor-EF-3.0 DateCode: 2020.7.10
==> Are reachable on deconz startup with all states getting updated, but after that they never get updated again.
The same here - blue dot blinking. But no refreshing of the states.

Of course I tested to reset and re-pair them - but with the same effect! They can be included to the network by Phoscon correctly, are getting one update and then stop working
Steps to reproduce the behavior

Steps to reproduce:

Start deconz gui mode - every node and sensor found!
Only effected Heimans get no status update at all, but are talking to the mesh from time to time. But (perhaps) nobody listens to them …
Tested over 35 hours!!! No updates!

Expected behavior

Like in deconz Version 2.12 before - every smoke sensor sends state updates (batteryPercent,batteryState,reachable,state,fire) within max 10 hours to deconz/phoscon. All kinds of Heiman clones did this before.

Status update in between 3-10 hours - battery, reachable,

Environment

Host system: Raspberry Pi 4
Running method: Raspbian Buster
Firmware version: 26780700
deCONZ version: (2.21.02)
Device: ConBee II
Do you use an USB extension cable: yes

deCONZ Logs

Tell me whats needed - I will post them. Which debug levels are important???

2

Please share some logs. In #deconz you can find out what levels :slight_smile:

3

I logged deCONZ from 8:15 - 10:52 but the log is way to big for pastebin 10MB. So I deleted many things… and it is still to big with the log setting:
/usr/bin/deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 | tee debug.txt

Is there an easy way to filter the log for you? Our how I can send you the whole log?

So I started with deconz startup:

Startup Startup DB

After no refreshing in Phoscon I triggered OG.Ar.Rauchmelder (SmokeSensor-EF-3.0) with the Test-Button. After that its getting refreshed… but like I said - then it stops getting updates - tested for 35 hours before. I searched for device mac and copied around…

OG.Ar.Rauchmelder - no updates

OG.Ar.Rauchmelder - triggered

I found a part where OG.Ar.Rauchmelder (12:18:06) talks…

OG.Ar.Rauchmelder - hours after triggering

but phoscon is still believing the last message came 10:44:04 - which was my test-button trigger.

Thanks

4

I check Monday when I’m at PC again.

5

Ok, feel free to ask for more specific log data on monday - I am at the PC, too.
Still logging since 8:15 today…

In my first Log I found wrong DB entries. DB thinks I am still using 2.12.06 and the wrong Firmware 0x26660700.

Phoscon knows better:

  • Version 2.21.02 / 19.9.2022
  • 26780700

Phoscon
Beam

6

Hi,

Logs doesn’t show anything worrying.

Can you provide me some longer logs (several minutes), to see whats going on in the network?

Additionally, can you provide a screenshot of your deCONZ gui (map with all the nodes)

Also: Can you provide a screenshot of the basic cluster of one of the sensors?

Kind regards,

7

Thats what I looks like in fhem (phoscon the most sensors are greyed out and not reachabel) after 3 days.
In 2.12 the biggest value was “for 3-6 hours not seen.”

Rauchmelder-Reachabel
Rauchmelder-Reachabel530Ă—805 57.9 KB

My network looks like this:

Nodes
Nodes1480Ă—729 236 KB

15 smoke sensors: (these are the 3 types I have for example)
A few of the SMOK_YDLV10 are still refreshing, but EF-3.0 and SF21 are dead/not reachable for phoscon at all!

Ke.Hz.Rauchmelder
00:50:43:c9:03:24:3a:3f
005043c903243a3f
manufacturername: Heiman
modelid: SMOK_YDLV10

OG.Ar.Rauchmelder
80:4b:50:ff:fe:ff:e8:06
804b50fffeffe806
manufacturername: HEIMAN
modelid: SmokeSensor-EF-3.0

OG.FL.Rauchmelder
00:0d:6f:00:10:dd:0c:6c
000d6f0010dd0c6c
manufacturername: HEIMAN
modelid: SF21 smoke sensor

Before killing the 3 days log and restart deCONZ-GUI for you ;), I pressed the test button for all the three sensors above and every sensor showed up in phoscon again - surprise!!!

When I looked at the log
Triggerd 3 sensors - after 99 hours not refreshing!,
the three showed up in phoscon again!

Longer Startup-Log

Basic Cluster Heiman EF-3:

BasicCluster-EF-3.0
BasicCluster-EF-3.0718Ă—696 93.8 KB

Basic Cluster Schwaiger ZHS20:

BasicCluster-Schwaiger-ZHS20
BasicCluster-Schwaiger-ZHS20811Ă—427 72.8 KB

Basic Cluster Orvibio SF21:

BasicCluster-Ovibio-SF21
BasicCluster-Ovibio-SF21835Ă—354 63.8 KB

8

Can you please provide a screenshot of the basic cluster?

9

Forgotten - I edited it above!

10

I have no clue whats happening with the second one.
@manup / @Smanar can you check the Orivbio screen (basic cluster). Has an odd Model identifier.

However, There has been 0 changes to the devices mentioned between those versions.

What i do notice, is that your network contains quiet a few bad connections. Is there a way for you to improve those?

11

Network had no problem over years … Yes, from time to time one or two smoke sensors got lost, but reset and re-pair an everything was good again for month.
House with 3 Floors and reinforced concrete ceilings.

But:
The three test-sensors are now 1m away from the Conbee II for testing. And like I said before, every sensor updates the phoscon sensor status immediately, if I press the test button - doesn’t matter if in cellar or elsewhere in the house.

12

Other example:

OG.K.FL.Rauchmelder
00:50:43:c9:03:24:42:8e
005043c90324428e
manufacturername: Heiman
modelid: SMOK_YDLV10

Was not moved neither far away from ConbeeII:
Status never got refreshed even after restart today, but in the log last night 4:42 and every 2h before - there are this entries - so why phoson does not notice, although it’s already logged by deconz with the right timestamps?
For me that’s not a weak connection problem.

Phoscon only says:
OG.K.FL.Rauchmelder

13

So, after comparing messages, which are send after hitting the test button and which are recognized by phoscon AND fhem correctly and the ignored 2-6hourly status updates by the sensors, which are never reaching phoscon or fhem…

phoscon/fhem don’t get informed about 2-6hourly sensor update messages looking like this:
22:23:03:325 Websocket 192.168.1.120:33684 send message: {“attr”:{“id”:“125”,“lastannounced”:null,“lastseen”:“2023-05-07T20:23Z”,“manufacturername”:“HEIMAN”,“modelid”:“SmokeSensor-EF-3.0”,“name”:“OG.Ar.Rauchmelder”,“swversion”:“2020.7.10”,“type”:“ZHAFire”,“uniqueid”:“80:4b:50:ff:fe:ff:e8:06-01-0500”},“e”:“changed”,“id”:“125”,“r”:“sensors”,“t”:“event”,“uniqueid”:“80:4b:50:ff:fe:ff:e8:06-01-0500”} (ret = -1092814640)

But by hitting the test-button: phoscon/fhem are succesfully updated with this message:
10:53:13:737 Websocket 192.168.1.120:33684 send message: {“e”:“changed”,“id”:“125”,“r”:“sensors”,“state”:{“fire”:true,“lastupdated”:“2023-05-08T08:53:13.736”,“lowbattery”:false,“tampered”:false},“t”:“event”,“uniqueid”:“80:4b:50:ff:fe:ff:e8:06-01-0500”} (ret = -1092815784)

So, why the messages look so different? Is it possible that this is the reason - can I test it by myself in any way?

14

Not sure why that happens. @de_employees perhaps you can help?

15

Nope it’s normal for orvibo, there is for exemple in code

        // replace ORVIBO model IDs
        if (lightNode.modelId() == QLatin1String("abb71ca5fe1846f185cfbda554046cce"))
        {
            lightNode.setModelId(QLatin1String("T10D1ZW dimmer"));
            lightNode.setNeedSaveDatabase(true);
        }
        else if (lightNode.modelId() == QLatin1String("545df2981b704114945f6df1c780515a"))
        {
            lightNode.setModelId(QLatin1String("T10W1ZW switch"));
            lightNode.setNeedSaveDatabase(true);
16

Today I restarted everything, again. Plugged off ConbeeII for at least 20min.
Rebooted RPI4.
Resetted and re-paired nearby OG.Ar.Rauchmelder (Smoke Sensor EF-3.0).

Still the same.
It and most of the other smoke sensors refreshed one time - and no other smoke-sensor status update packet received by deconz (and there are lot of) are getting through to phoscon or fhem like I explained before.

Log is full with status updates from all smoke sensors, but no state gets refreshed (except a bunch of Schwaiger ZHS20 - SMOK_YDLV10 are still updating - but no EF-3.0 or SF21)!
Phoscon even sees less information (unreachable - no battery values - never seen), as if I start rest-api and request the sensor id for a specific sensor or ask fhem through rest-api I can even see more information.

Still only pushing test-button, updates every sensor immediately

So, really clueless…

17

Let’s see if / when Dresden elektronik people reply with a solution.
In the meanwhile, i recommend getting more routers as you might get some more to optimize things.

18

Offtopic:

"Optimizing is quite complicated.
The best ceiling-floor-hop experience I have with Conbee II, Heiman Siren and Heiman Gassensor… they are the backbone of the hole mesh over all floors.
In every floor there are several Ikea Tradfri Trafo, Ledvance/Osram Plugs, Innr Plugs, Nous Plugs, but they have all not the same signal strength through ceilings.

So what are your signal-strength favorites? - A second siren or gassensor are useless to me!"

19

You need routers. Mains powered devices.

20

Heiman Siren and Heiman Gassensor are mains powered devices! :wink:
And Osram, Innr, Nous are to weak for the ceiling hop - the mesh likes the route Conbee II, Heiman Siren, Heiman Gassensor.