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

cosmo84 · March 15, 2024, 7:30am

I made some more tests with interesting results:

I replaced the battery of my CO sensor which was down to ~20%.
I put this old battery into one of my fire sensors and the battery status of the fire sensor gets immediately updated to 15%, low battery set to 1

[3/15/2024, 8:18:05 AM] [deCONZ] Flur UG Battery: Battery Level: set to 15% (from 100%)
[3/15/2024, 8:18:05 AM] [deCONZ] Flur UG Battery: Status Low Battery: set to 1 (from 0)

Then I put the previous battery of the fire sensor back in which is about 2,5 years old. Back to 100%:

[3/15/2024, 8:19:22 AM] [deCONZ] Flur UG Battery: Battery Level: set to 100% (from 15%)
[3/15/2024, 8:19:22 AM] [deCONZ] Flur UG Battery: Status Low Battery: set to 0 (from 1)

My summary:

CO measurement seems to consume much more battery than a fire sensor
Heiman fire sensors do transmit battery state in a correct way
Heiman fire sensors might transmit battery state changes only in case of a change in the value and even though it’s hard to believe there is no change after 2,5 years

That said it seems to me there is no real issue with battery state transmission. What remains is the fact that the devices don’t update the “last seen” values in the API. I just checked and even for the fire sensor where I replaced the battery, it transmitted the new battery values but the last seen value remains at 28 days ago.

The same by the way for the Heiman CO sensor which says last seen 40 days ago

Smanar · March 15, 2024, 3:31pm

Yeah.

If you have take look at the value using the GUI, it have forced a read value, so the field in the API NEED to be updated

Can you share the complete device json ? with “lastseen” and “lastupdated”. You can find it in phoscon/help/API Information/sensors

cosmo84 · March 15, 2024, 4:19pm

Here it is:

{
“config”: {
“battery”: 100,
“on”: true,
“pending”: ,
“reachable”: true
},
“ep”: 1,
“etag”: “86b2ab065644cfaf753158e537418bfb”,
“lastannounced”: “2024-03-15T07:19:19Z”,
“lastseen”: “2024-03-15T16:05Z”,
“manufacturername”: “HEIMAN”,
“modelid”: “SmokeSensor-EF-3.0”,
“name”: “Flur UG”,
“state”: {
“fire”: false,
“lastupdated”: “2024-02-15T10:55:38.757”,
“lowbattery”: false
},
“swversion”: “2019.8.29”,
“type”: “ZHAFire”,
“uniqueid”: “84:71:27:ff:fe:7f:58:4b-01-0500”
}

lastseen is okay, but lastupdated is a month ago

Smanar · March 15, 2024, 6:40pm

And you have a “last seen” > 24h in phoscon ?
And it’s the device you have trigger a “state/fire” recently to test ?

cosmo84 · March 15, 2024, 7:08pm

This is how it looks in Phoscon:

It was most probably the day where I last made a test alarm. But I would expect that the date is today where I exchanged the battery. Or any other newer point afterwards. The sensors seem to send updates quite regular, about once in an hour. All other sensors I have ( water leak, door/window, gas) usually have a last update in the range of the last hour.

Swoop · March 15, 2024, 9:15pm

Everything is fully within expectations, lastseen != lastupdated

Lastseen is current, as the device constantly communicates, lastupdated was apparently the time (as you already guessed) the time of your test alert. Note that it is within the state and therefore only applies to it.

cosmo84 · March 16, 2024, 6:04pm

Okay thanks. I keep monitoring it.

SvenMartin81 · November 1, 2024, 7:45pm

Hi,
I have a similar/same problem with these smoke sensors. I have 6 sensors. and 2 of them are always not connected. I tried to reconnect (delete them and learned them again) but nothing happend.

                {
"config": {
    "battery": 100,
    "enrolled": 0,
    "on": true,
    "pending": [],
    "reachable": false
},
"ep": 1,
"etag": "a3b395c1f9832288fa65019b06703ca7",
"lastannounced": "2023-08-17T08:04:31Z",
"lastseen": "2024-01-10T09:01Z",
"manufacturername": "Heiman",
"modelid": "SmokeSensor-EM",
"name": "Rauchmelder Amelie",
"state": {
    "fire": null,
    "lastupdated": "none",
    "lowbattery": null,
    "tampered": null
},
"swversion": "1.1.1",
"type": "ZHAFire",
"uniqueid": "00:0d:6f:00:16:48:3f:ef-01-0500"

}

BeamMeUpTo · April 24, 2025, 4:06pm

Hi @All, after 2 years of having no problems

I had no troubles with deconz 2.22 to 2.26.3 … but then
I upgraded to 2.29.5 because of some new sensors.

Everything looked good.
Then I realize that my old problem is back.

The 15 smokesensor devices of the Heiman-Clan (Heiman/Orvibio SF21, Heiman SmokeSensor-EF-3.0 and Heiman/Schwaiger ZHS20)
get no rest-api timestamp update when refreshing battery values.
I can’t even see them refreshing it all… wasn’t it: ZCL got data 0x0021 - I can’t see any lines combined with any of my smokesensor.

Were there changes lately from 2.26.3 to 2.29.5 which effect me???
All of them are running with boxed ddf.

If I press any test button they react immediately and get new timestamps.

If I restart deconz they all get a fresh timestamps and then never again.

Last logging is long time a go … what do you need?

Smanar · April 24, 2025, 5:37pm

Hello, can you paste a json from a not updating device ? To see lastseen and lastupdated ?
I m checking the code, no change on the DDF on last 5 months, and previous one was cosmetic, lot of changes on the deconz core, but no change on this issue from what I m seing.

BeamMeUpTo · April 24, 2025, 6:10pm

Here is one json of each type of sensors.
Normally the last years no sensor was longer not seen/refreshed by battery state than 3 hours. Now they lost the whole day.
Now the are away for 9 hours.
9 hours because of deconz restart.

EG.KN.Fl.Rauchmelder 000d6f001366a187
Orvibio SF21

{
    "capabilities": {
        "sleeper": true
    },
    "config": {
        "battery": 100,
        "on": true,
        "pending": [],
        "reachable": true
    },
    "ddf_hash": null,
    "ddf_policy": "latest_prefer_stable",
    "ep": 1,
    "etag": "99bb10045486c17e4ce7252665c5acb2",
    "lastannounced": null,
    "lastseen": "2025-04-24T16:28Z",
    "manufacturername": "Heiman",
    "modelid": "98293058552c49f38ad0748541ee96ba",
    "name": "EG.KN.FL.Rauchmelder",
    "nwkaddress": 30541,
    "state": {
        "fire": false,
        "lastupdated": "2025-03-12T08:10:53.024",
        "lowbattery": false
    },
    "swversion": "1.1.1",
    "type": "ZHAFire",
    "uniqueid": "00:0d:6f:00:13:66:a1:87-01-0500",
    "zonetype": null
}

OG.K.FL.Rauchmelder 005043c90324428e
Schwaiger ZHS20 SMOK_YDLV10

{
    "capabilities": {
        "sleeper": true
    },
    "config": {
        "battery": 100,
        "on": true,
        "pending": [],
        "reachable": true
    },
    "ddf_hash": null,
    "ddf_policy": "latest_prefer_stable",
    "ep": 1,
    "etag": "eb5a2e4df225c5f591b986928e12f0ca",
    "lastannounced": null,
    "lastseen": "2025-04-24T16:20Z",
    "manufacturername": "Heiman",
    "modelid": "SMOK_YDLV10",
    "name": "OG.K.FL.Rauchmelder",
    "nwkaddress": 10167,
    "state": {
        "fire": false,
        "lastupdated": "2025-04-19T12:23:39.242",
        "lowbattery": false
    },
    "swversion": "20150330",
    "type": "ZHAFire",
    "uniqueid": "00:50:43:c9:03:24:42:8e-01-0500",
    "zonetype": null
}

EG.Ar.Rauchmelder
Heiman SmokeSensor-EF-3.0

{
    "capabilities": {
        "sleeper": true
    },
    "config": {
        "battery": 100,
        "on": true,
        "pending": [],
        "reachable": true
    },
    "ddf_hash": null,
    "ddf_policy": "latest_prefer_stable",
    "ep": 1,
    "etag": "e82fe03260a2746bcc615f6cd26d614c",
    "lastannounced": null,
    "lastseen": "2025-04-24T17:25Z",
    "manufacturername": "Heiman",
    "modelid": "SmokeSensor-EF-3.0",
    "name": "EG.Ar.Rauchmelder",
    "nwkaddress": 34307,
    "state": {
        "fire": false,
        "lastupdated": "2024-12-21T23:44:47.830",
        "lowbattery": false
    },
    "swversion": "2020.7.10",
    "type": "ZHAFire",
    "uniqueid": "84:fd:27:ff:fe:04:5c:23-01-0500",
    "zonetype": null
}

fhem rest-api access battery state gets not updated

BeamMeUpTo · April 25, 2025, 8:59am

After posting the jsons for the 3 sensors… I was wondering
I checked the other sensors, too.
The result was that every sensor has lastseen timestamps not older than 3-5 hours. If I check them with the api tool.

So my problem seems to be according to the log, that the websocket notification gets not generated only for the smoke sensors and only for other computers than the one fhem and deconz are running on?

I checked my config but:

"websocketnotifyall": true,

Is this possible? How to solve?
Thanks

Smanar · April 25, 2025, 5:08pm

There is only one API, and all third app are using the same.
So you are saying if you check direclty in the API the lastseen is fine but third app don’t use the value ?

You can check the websocket event too, can use a browser plugin or use Phoscon/help/API information/event, you can use filter to decrease talking…

BeamMeUpTo · April 25, 2025, 6:49pm

I know.

Exactly! But only for all the smokesensors since upgrade to 2.29.5.

All other sensors/lights have no problem. And are always up to date.

Smanar · April 26, 2025, 10:35am

And you see the “missing websocket” on wich one third app ? Phoscon and FHEM ?

So to resume you miss the websocket even for “lastseen” but only on one device model ? and the API is fine.

BeamMeUpTo · April 26, 2025, 11:30am

The API seems to be fine.

Today I deleted 2 of the sensors and re-paired them and had to restart fhem/deconz server several times.

Now I can see websocket messages for both deconz/phoscon on 192.168.1.120 and
for fhem webbrowser window on 192.168.1.45 for the smoke sensors and every other.

Funny thing is.
Nothing happens (no new timestamps for lastseen, battery and so on) on the fhem side if this message arrives:

12:29:41:741 Websocket 192.168.1.120:49582 send message: {"attr":{"ddf_hash":null,"ddf_policy":"latest_prefer_stable","lastannounced":null,"lastseen":"2025-04-26T10:29Z","manufacturername":"Heiman","modelid":"SMOK_YDLV10","name":"OG.Sz.Rauchmelder","nwkaddress":26547,"swversion":"20150330","type":"ZHAFire","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500","zonetype":40},"e":"changed","id":"174","r":"sensors","t":"event","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500"} (ret = 407)
12:29:41:744 Websocket 192.168.1.45:54520 send message: {"attr":{"ddf_hash":null,"ddf_policy":"latest_prefer_stable","lastannounced":null,"lastseen":"2025-04-26T10:29Z","manufacturername":"Heiman","modelid":"SMOK_YDLV10","name":"OG.Sz.Rauchmelder","nwkaddress":26547,"swversion":"20150330","type":"ZHAFire","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500","zonetype":40},"e":"changed","id":"174","r":"sensors","t":"event","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500"} (ret = 407)
12:29:41:749 DEV Binding read bindings /devices/0x005043C90335653D

Only if this message is send with the battery values fhem recognizes, that there is new actual data - that was the reason I always checked the battery timestamp for my own value NotSeen4hours:

12:13:11:536 SensorNode id: 174 (OG.Sz.Rauchmelder) available
12:13:11:538 SensorNode id: 173 (OG.Ar.Rauchmelder) available
12:13:11:542 rule event /config/localtime: 12:13:10.536 -> 12:13:11.536 (1000ms)
12:13:11:544 Websocket 192.168.1.120:49582 send message: {"config":{"battery":100,"on":true,"pending":[],"reachable":true},"e":"changed","id":"174","r":"sensors","t":"event","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500"} (ret = 162)
12:13:11:545 Websocket 192.168.1.45:54520 send message: {"config":{"battery":100,"on":true,"pending":[],"reachable":true},"e":"changed","id":"174","r":"sensors","t":"event","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500"} (ret = 162)
12:13:11:547 Websocket 192.168.1.120:49582 send message: {"config":{"battery":100,"on":true,"pending":[],"reachable":true},"e":"changed","id":"173","r":"sensors","t":"event","uniqueid":"80:4b:50:ff:fe:ff:e8:06-01-0500"} (ret = 162)
12:13:11:550 Websocket 192.168.1.45:54520 send message: {"config":{"battery":100,"on":true,"pending":[],"reachable":true},"e":"changed","id":"173","r":"sensors","t":"event","uniqueid":"80:4b:50:ff:fe:ff:e8:06-01-0500"} (ret = 162)

Lastseen gets not refreshed on the fhem side - although rest-api did send correct data.
BUT Only for the smoke sensors!
Heiman GASSensor-EM for example makes all the refreshing of all values even lastseen. Real strange - can’t find the difference.

Smanar · April 26, 2025, 12:28pm

Lol, so for information I m the dev of the Deconz plugin on Domoticz and I m doing same ^^.

12:13:11:544 Websocket 192.168.1.120:49582 send message: {"config":{"battery":100,"on":true,"pending":[],"reachable":true},"e":"changed","id":"174","r":"sensors","t":"event","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500"}

This websocket provoque a “last seen” update on the app only

if the value change
maximum 1 update every 24h if there is no change.

It’s because all events are logged (and it’s my choice ^^) and for me 1 report every 24h is enought to see if a device is alive or not, no need to fill databasqe without useless data.

12:29:41:741 Websocket 192.168.1.120:49582 send message: {"attr":{"ddf_hash":null,"ddf_policy":"latest_prefer_stable","lastannounced":null,"lastseen":"2025-04-26T10:29Z","manufacturername":"Heiman","modelid":"SMOK_YDLV10","name":"OG.Sz.Rauchmelder","nwkaddress":26547,"swversion":"20150330","type":"ZHAFire","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500","zonetype":40},"e":"changed","id":"174","r":"sensors","t":"event","uniqueid":"00:50:43:c9:03:35:65:3d-01-0500"}

This one is ignored, no data usefull for me.

So IDK how work the FHEM plugin, but the dev can have do same choice than me.

Other device can make battery report, so the application update the “last seen” (the battery report is usefull for me too), but the “lastseen” websocket made by deconz (without usefull data) is ignored on my app too.

BeamMeUpTo · April 26, 2025, 4:53pm

Ah… good to know. Took me a while to get this clear.

I can live with “attr” messages with “lastseen” being ignored but “config” messages with actual or even the same battery data, I would like to receive.
Here I’m kind of paranoid - I like my sensors giving a heart beat every 3-5 hours.
And every other battery powered sensor in my zigbee network does it.

Only the smoke sensor not anymore - after the upgrade.
So what changed in deCONZ? - nothing was changed in my fhem environment.

Today I got plenty of “attr” messages from all smoke sensors in the logs, but only one “config” battery message for nearly every sensor!

I there a way to overrule this by ddf? I tested with “refresh.interval”: 7100 nearly 2 hours, but nothing happend. All three ddfs look a bit diffrent.
Some advice for me? How to force “config” battery messages?
Or is this hard coded in deconz/phoscon and ddf settings are ignored for same battery values?
Thanks

Smanar · April 26, 2025, 5:21pm

IDK, if there is something different on the recent version, but yes for exemple for the

SMOK_YDLV10

The reporting is set here

    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 1,
          "max": 7200,
          "change": "0x00000001"
        }
      ]
    },

From this setting the device need to make a battery report to deconz at least every 7200 s.
So deconz need too make the websosocket report too.

The refresh.interval is a security if the report don’t work, so the value need to be superior.

BeamMeUpTo · April 27, 2025, 7:22am

So far - after logging for 20h… with boxed ddf.

SMOK_YDLV10 and Orvibo SF21are generating every 2 hours an “attr” messages with “lastseen” report.
But the whole day max only one battery report after restarting deconz - Is there something mixed up? Because you said, ddf ^^ (like the boxed one with 7200) should generate an “config” battery report every 2 hours, but it does an “Attr” report every 2 hours, which is useless for me.

Try to find my old ddf in a backup and compare them with the new one, but I guess they look very similar.
Nice, sunny sunday

Did compare Orvibo sf21:
my old one:

"parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Attr.val / 2",
            "fn": "zcl"                         <-- !!! no attr!!!

new one:

"parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Attr.val / 2",
            "fn": "zcl:attr"
          },
          "read": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "fn": "zcl:attr"       <--- !!!!! attr!!!
          }

Same in heimann hs1sa_smoke_sensor.json
Whats the correct “fn”: for calling config? “fn”:“zcl:config” ???