Had the same issue and added more Heiman Siren as well. They are indeed one of the best routers I have. I also thought IKEA Plugs or more Bulbs would help, but only Heiman Siren (not the Heiman night light) did the trick.
1 Like
Offtopic: āGood to hear - Iām not totally wrong 
What about Tradfri Repeater in comparison? Does anybody know?ā
So I investigated to problems again today:
I started logging again at 9:52 today. And only focused on
Heiman Model: SmokeSensor-EF-3.0.
Here is the cutted log from what I did:
- 9:50 DeCONZ debug log start.
- 11:43, 12:29, 13:14, ā¦ Sensor status is not updated at all. Sensor speaks with the mesh - but every time there is no āwebsocket send messageā generated. Is the status saved somewhere in DB - I canāt see this.
- 13:22 pushed the Test-Button (Everything is commented in the Log and phoscon/fhem are updated with new status)
So my result so far is:
-Sensor is talking to mesh every hour, but no websocket send message is generated.
-If I hit the Test-Button everything works as normal.
-
10:58:31:097 0x804B50FFFEFFE806 error APSDE-DATA.confirm: 0xF0 on task
-
10:58:31:097 Erase task req-id: 231, type: 19 zcl seqno: 138 send time 7, profileId: 0x0104, clusterId: 0x0500
-
10:58:31:098 APS-DATA.confirm id: 231, status: 0xF0 TRANSACTION_EXPIRED
-
10:58:31:098 APS-DATA.confirm id: 231 status: transaction expired
No clue where that comes from. Iāve asked @swoop to check in.
So now the real weird!
DB.Rauchmelder (same model complete different behaviour)
84:fd:27:ff:fe:04:5c:89
84fd27fffe045c89
manufacturername: Heiman
modelid: SmokeSensor-EF-3.0
Here comes the Log:
No status updates at all - BUT: āwebsocket send messagesā are generated! Phoscon/fhem are ignoring them at all even after restarting deconz
Pushing the Test-Button - every status gets updated!!!
Later I will make the same for the other two Heiman models ā¦
I have the same sensors. Can you explain what you expect? To me it is quite normal that the devices donāt report any update while theyāre sleeping. Also mine are just reporting something new, if I push the test button. Then, immediately my fire alarm is triggered.
So all in all, I donāt care if these devices are sleeping until they detect smoke. This saves battery.
Am I wrong?
After the above, i am wondering the same.
But they arenāt sleeping they send status update every 3-6 hours - like my log shows - why should I waste them? They are already sent! - I want to know if the battery drains or device is not reachable.
I expect every 2-6h a status update from ALL smoke sensors, like it was with deconz 2.12.xx:
For refreshing: Battery, Batterypercent, batteryState, lastseen, reachabel, state, tampered (fake), and so on
Every smoke sensor was at least seen by its own by phoscon/fhem every 6 hours with deCONZ 2.12.xx- naturally without āreal fireā OR hitting the ātest-buttonā!
Because itās not helpful (for an āintelligentā sensor), if phoscon/fhem are getting no status updates regularly, before I push the test-button** every 6 hours to see, if the battery drained or the device is not reachable at all.
Important!!!:
Phoscon/fhem donāt get these regularly updates even, if they are somtimes allegedly sended (like logged in the log, but like I wrote in the comments of each log, they never reach phoscon or fhem! Why?
The only message which refreshes the EF-3.0 Device in phoscon/fhem is hitting the test-button like I told once or twice before.
And I want to know why the āregularly status updatesā are gone/ or do not reach/refresh fhem/phoscon at all even if they are sent - like the logs are showing!!!
Only 4 of 15 sensors are doing this right and are seen every 3-6hours . (All Schwaiger ZHS20 (Heiman) SMOK_YLDV10 devices)
Hours count āVor x h gesehenā is calculated by status update āreachableā and if its not updated for hours, then āhours not seenā count increases for ever. Like Wz.KN.Rauchmelder does 152h not seen, because of no updates - even if it talks to the network regularly.
Again: Only test-button refreshes the device and 152 hours drops to 0h.
Only these 4 (All Schwaiger ZHS20 (Heiman) SMOK_YLDV10 devices) are working right after the upgrade to 2.21.02.
OG.Kathi.Rauchmelder
Ke.Hz.Rauchmelder
OG.K.Sz.Rauchmelder
OG.Sz.Rauchmelder
Like shown in the picture. Every sensor with āhours count not seenā (Vor x h gesehen) greater than 6 hours will never be updated again! Until āfireā breaks out or I hit the ātest-buttonā.
There are several events logged in deCONZ for refreshing this sensorā¦ But the only logged one is the test-button!
OG.Ar.Rauchmelder (EF-3.0) is not generating an āwebsocket send messageā event at all!!!
Only test-button event is refreshing phoscon with actual status updates like I did at 13:22!
DB.Rauchmelder (EF-3.0, too) is generating the the āwebsocket send messageā event -
BUT: phoscon/fhem are missing it! Why?
Same here: There are several events logged in deCONZ for refreshing this sensorā¦ But the only logged one is the test-button event I generated at 15:31!
Every other sensor (Aqara, Eurotronic Spirit, ā¦ ) in the hole network has no problem and is sending its updates regularlyā¦
Now understandable? I hope soā¦ If not feel free to ask!
Iām not really sure where to start here since itās unfortunately so many bits and pieces mixed together, but allow me to address a couple of points:
The last snippets of log data shared do whitness the sensors report battery data. Those are from my perspective already enough to conclude that attribute reporting is configured (and data comes in via ZCL command 0x0A = attribute reporting). For any data coming from the IAS Zone cluster, I do not know what the devices are capable of. Top class products support supervision and restore reports (although weāve also seen this is not adhered to), which basically means they send some status updates on a regular basis on the fire state and when a fire condition is resolved. Iād assume this is not the case for any for the sensors, with a small chance that Iām wrong here. So, to sum that up, the āregular device updatesā would be battery data.
One thing worth to note regarding REST API is that you can configure if all resource data is sent upon any change or just the changed items/values. Respective configuration item is called websocketnotifyall. Based on what we see, Iād assume this is set to false?
Regardless, the below can serve as an example.
11:59:11:036 Node data 0x84fd27fffe045c89 profileId: 0x0104, clusterId: 0x0001
11:59:11:037 0x84FD27FFFE045C89: update ZCL value 0x01/0x0001/0x0021 after 0 s
11:59:11:037 [INFO] - No button map for: SmokeSensor-EF-3.0, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0001, command: 0x0A, payload: 210020C8, zclSeq: 81
11:59:11:037 ZCL attribute report 0x84FD27FFFE045C89 for cluster: 0x0001, ep: 0x01, frame control: 0x18, mfcode: 0x0000
11:59:11:037 payload: 210020c8
11:59:11:037 Websocket 192.168.1.120:59486 send message: {"attr":{"id":"95","lastannounced":"2022-09-17T18:45:53Z","lastseen":"2023-05-10T09:59Z","manufacturername":"Heiman","modelid":"SmokeSensor-EF-3.0","name":"DB.Rauchmelder","swversion":null,"type":"ZHAFire","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"} (ret = -1095568296)
11:59:11:037 Websocket 192.168.1.44:46154 send message: {"attr":{"id":"95","lastannounced":"2022-09-17T18:45:53Z","lastseen":"2023-05-10T09:59Z","manufacturername":"Heiman","modelid":"SmokeSensor-EF-3.0","name":"DB.Rauchmelder","swversion":null,"type":"ZHAFire","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"} (ret = -1095568296)
Here we see a battery attribute report arriving at zigbee level and the value is processed. The actual value is 200 and presumably, the previous value was 200 as well. As previous and new value equal, the battery would be skipped in the websocket notification. However, since some new data came in lastseen value is updated nevertheless.
What I recall from the respective FHEM module is that timestamp processing was really bad and just wrong in my view. They werenāt available as readings and as such, no update would ever occur. One of the main issues I had back in the days.
While this is a possible explanation, I do not know if there might be some hidden issue with the websocket messages regardless. I explicitly configured the API to only send updated values and not everything the device sensor has or offers. If a potential issue ājustā manifests when everytingās supposed to be sent, I would have never regognized that.
Regarding Phoscon, it is worth to note that is is just another REST API client as the FHEM module(s). Could be that the above applies, could also be that it just gives an updated time when a state is updated (battery is a config attribute).
One definitive difference of the devices is that the Schwaiger is based on a DDF and the others are based on legacy. Maybe itās worth to create some and check if that makes any differenceā¦
Lastly, it would be very beneficial of have a significantly larger log of about 3-4 hours, as information which is currently missing/not available is telling us quite a story and would probably also allow us to spot potential differences or prove/discard theories. In that sense, the command line flag --dbg-aps=2 could be left out for now, which would also significantly shrink file size.
1 Like
Yes, it is a bit confusing - so perhaps we stay first with the Heiman Model: SmokeSensor-EF-3.0.
websocketnotifyall: false ā That would have explained things.
A battery state "update from 100% before and 100% after the next report would be ignored - Am I right?
But:
Mine is already true - and battery state gets not updated. Why?
get http://192.168.1.120/api/xxxxxxx/config
shows that is:
"swversion": "2.21.2",
"timeformat": "24h",
"timezone": "Europe/Berlin",
"uuid": "fcc0d2f2-2373-42c1-a626-09eed7510f8a",
"websocketnotifyall": true,
"websocketport": 443,
"whitelist": {
"00580554EF": {
"create date": "2019-06-03T19:59:26",
"last use date": "2019-06-03T20:02:03",
"name": "Phoscon#B1525x690"
},
The update data has to be stored in database file for rest-api access - Is that right? Can I check this by debug log - data? Or somewhere else?
A get http://192.168.1.120/api/XXXX/sensor/128
shows the same old data.
But the question is still, why two of the same model devices (HeimanEF-3.0) devices behave differently?
OG.Ar.Rauchmelder - status (battery) refreshes BUT no "websocket send message" at all!
10:58:19:877 Node data 0x804b50fffeffe806 profileId: 0x0104, clusterId: 0x0001
10:58:19:877 0x804B50FFFEFFE806: update ZCL value 0x01/0x0001/0x0021 after 0 s
10:58:19:877 [INFO] - No button map for: SmokeSensor-EF-3.0, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0001, command: 0x0A, payload: 210020C8, zclSeq: 57
10:58:19:877 ZCL attribute report 0x804B50FFFEFFE806 for cluster: 0x0001, ep: 0x01, frame control: 0x18, mfcode: 0x0000
10:58:19:877 payload: 210020c8
10:58:20:394 poll node d0:cf:5e:ff:fe:26:ce:5c-01
DB.Rauchmelder - status (battery) refreshes and āwebsocket send messageā, but they are never reaching the database/phoscon/fhem - Why? Are the malformed??? If not: Where/Why do they stuck?
10:28:18:320 APS-DATA.indication srcAddr: 0x2ce1, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0001, lqi: 255, rssi: -67
10:28:18:320 asdu: 184f0a210020c8
10:28:18:320 Node data 0x84fd27fffe045c89 profileId: 0x0104, clusterId: 0x0001
10:28:18:321 0x84FD27FFFE045C89: added ZCL value 0x01/0x0001/0x0021
10:28:18:321 [INFO] - No button map for: SmokeSensor-EF-3.0, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0001, command: 0x0A, payload: 210020C8, zclSeq: 79
10:28:18:321 ZCL attribute report 0x84FD27FFFE045C89 for cluster: 0x0001, ep: 0x01, frame control: 0x18, mfcode: 0x0000
10:28:18:321 payload: 210020c8
10:28:18:321 Websocket 192.168.1.44:57906 send message: {"attr":{"id":"95","lastannounced":"2022-09-17T18:45:53Z","lastseen":"2023-05-10T08:28Z","manufacturername":"Heiman","modelid":"SmokeSensor-EF-3.0","name":"DB.Rauchmelder","swversion":null,"type":"ZHAFire","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"} (ret = -1095568296)
10:28:18:321 Websocket 192.168.1.120:59486 send message: {"attr":{"id":"95","lastannounced":"2022-09-17T18:45:53Z","lastseen":"2023-05-10T08:28Z","manufacturername":"Heiman","modelid":"SmokeSensor-EF-3.0","name":"DB.Rauchmelder","swversion":null,"type":"ZHAFire","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"} (ret = -1095568296)
10:28:18:321 Websocket 192.168.1.44:57906 send message: {"config":{"battery":100,"enrolled":0,"on":true,"pending":[],"reachable":true},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"} (ret = -1095568296)
10:28:18:322 Websocket 192.168.1.120:59486 send message: {"config":{"battery":100,"enrolled":0,"on":true,"pending":[],"reachable":true},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:04:5c:89-01-0500"} (ret = -1095568296)```Forgot to mention:
But that would be viewable at phoscon or am I wrong? Picture from today - and nothing happened to ālastseenā since yesterday, although the sensor sends updates and talks hourly with network. Or is there somewhere another ālastseenā?
Itās a new status picture from now!
By the way - I restarted the log with:
deCONZ -platform minimal --dbg-info=2 --dbg-error=2 | tee debug.txt
After half an hour it has 1,7MB! ā 3 hours is then way to big for pastebin.
How can I send it to you?
Today logged a 11:57 ---- ālastseenā:ā2023-05-11T09:57Zā
11:57:51:683 Websocket 192.168.1.120:59948 send message: {"attr":{"id":"128","lastannounced":null,"lastseen":"2023-05-11T09:57Z","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":"128","r":"sensors","t":"event","uniqueid":"80:4b:50:ff:fe:ff:e8:06-01-0500"} (ret = -1098700576)
11:57:51:683 Websocket 192.168.1.44:34952 send message: {"attr":{"id":"128","lastannounced":null,"lastseen":"2023-05-11T09:57Z","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":"128","r":"sensors","t":"event","uniqueid":"80:4b:50:ff:fe:ff:e8:06-01-0500"} (ret = -1098700576)
11:57:51:692 APS-DATA.indication from child 0x6AEF
11:57:51:692 Node data 0x804b50fffeffe806 profileId: 0x0104, clusterId: 0x0001
11:57:51:692 0x804B50FFFEFFE806: update ZCL value 0x01/0x0001/0x0021 after 0 s
11:57:51:692 [INFO] - No button map for: SmokeSensor-EF-3.0, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0001, command: 0x0A, payload: 210020C8, zclSeq: 96
11:57:51:692 ZCL attribute report 0x804B50FFFEFFE806 for cluster: 0x0001, ep: 0x01, frame control: 0x18, mfcode: 0x0000
11:57:51:692 payload: 210020c8
11:57:51:899 Wait 2s till query finished
Screenshot at 12:43 today: But Phoscon does not refresh ālastseenā - Why?
@BeamMeUpTo A moderation note: can you please update you previous post instead of adding new posts when theres an update?
2 Likes
I checked all my Heiman Smoke Detectors now in phoscon as well. All except one (that I tested yesterday) have a status ānot reachableā in phoscon, while at the same time they are not marked āgreyā in the overview and deCONZ shows a connection line to the parent. ioBroker shows reachable = true, but there is no update since months. Iām pretty sure they all work fine, once I trigger a test, but this is somewhat strange indeed.
Additionally: Same applies to Heiman CO detectors.
Thomas
Same as here - like I said - but believe me, with deCONZ 2.12.x - and earlier - I think I started with 2.05 and I started the device request for Orvibo and Schwaiger years ago, too, every Heiman smoke sensor got refreshed in database for rest-api in one to three or sometimes in 6 hours.
I uploaded the log from today without aps2 to google drive. 25MB
So perhaps somebody can find out, which functionality got lost in the meanwhile or is hidden behind a new feature.
Why the smoke sensors are talking the whole day with the mesh and are refreshing ālastseenā, but no instance like the database is saving the last refresh for the rest-api respectively phoscon/fhem.
OG.Ar.Rauchmelder (804b50fffeffe806) does this every hour, and phoscon is still believing, that it saw him yesterday on 10.5.23 at 13:22 the last time - but this was the last test-button hit - The only message which ended up in the database for rest-api. (Like I told U already - once or twice )
So every update of the sensor in the log is dismissed!
The only exception is hitting the test-button - This message gets through @ once!
If you need still more information besides the mega-log - tell me!
I will change my name to (Like I told U already - once or twice ) 
Hammering this thread is not exactly helpful while asking questions you expect an answer on 
Although you shared only some tiny pieces of log data which have been ripped out of context and also been put into misleading order, I havenāt seen anything thus far which is not explainable. Anyway, to answer your question spread a gazillion times: Phoscon doesnāt update the time as it doesnāt seem to use lastseen, but lastupdated. lastupdated only changes if state attributes get updated, and battery is a config attribute.
The question now is, as indicated previously, why not all attributes are sent when websocketnotify is set to true. Eventually, there have been some changes over time or something got broken. And if, btw, the wrong timestamp is used for setting reachable, it would also explain why the devices seemingly get lost.
On a side note, never use reachable to determine availability of a sensor, thatās whatās lastseen is for.
Sorry - Iām not hammeringā¦ this thread! - I try to provide answers for questions that nobody asks! Say exactly what you need and how you want to get it!
Yes, because of a lack of information what exactly you need. The log you wanted to have, needed some time and I tried to provide infos before the log is finished. And nobody - by the way - is telling here how you will get that monster log! So I found my own way with google-drive.
For me the real difference between lastseeen and lastupdated - is not clear - Iām not into the depth of programming deCONZ rest-api like you are, thatās because Iām asking here! Config attribute/state attribute - Iām not into it, too!
Try to be helpful - like I try to be all the time!
lastseen - lastupdated- for me it is the same - even if it isnāt. I want to have one value that is refreshed several times a day for knowing if the sensor is still alive - phoscon does not notice any of them at all. Why?
I generated a real huge log - more isnāt possible for me. I can only say, that none of the EF-3.0 smoke sensors is refreshed since yesterday! Although sensor speaks every hour with the network - answers reaches deCONZ - so why it is not logged anywhere. What is the problem - what you need to solve it - besides my mega-log that I did today?
Tell me! I will try to deliver it in the right order!
Nah, Iām not going down that alley nowā¦
Try to be helpful
Well, actually I thought I was by explaining possible reasons and answering your primary question why āAktualisiertā is not changing/updating. Apparently, I didnāt, please apologize.
lastseen-lastupdated- for me it is the same - even if it isnāt. I want to have one value that is refreshed several times a day for knowing if the sensor is still alive - phoscon does not notice any of them at all. Why?
What should I say? It isnāt and I thought itās explained above. Maybe Phoscon should present the right one or revert any potential change in this regard.
I, personally, wouldnāt need any further log data. Iād just be curious how it is possible deconz deems a reporting sensor as not reachable although itās sending reports 
No shit, thereās apparently a real bug involved here affecting only legacy devices not having a DDF. You never catch that if you just look at the codeā¦ Need to do some more testing to be sure.
In that case, please submit a bug report with the exact details on it. After you conclude your tests.
Bug report - Nice work! Good you found something, that could explain it! Thanks 
Oh, already merged into code - so I wait for 2.22.1 beta!