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.