Failed data request failed with error mac transaction expired 240

Comments

{
    "type": "devices",
    "message": [
        {
            "ieeeAddr": "0x00124b0001536f96",
            "type": "Coordinator",
            "networkAddress": 0,
            "friendly_name": "Coordinator",
            "softwareBuildID": "zStack12",
            "dateCode": "20190608",
            "lastSeen": 1591971948249
        },
        {
            "ieeeAddr": "0xd0cf5efffeea28ef",
            "networkAddress": 24046,
            "vendor": "-",
            "description": "-",
            "friendly_name": "0xd0cf5efffeea28ef",
            "lastSeen": 1591957604663
        },
        {
            "ieeeAddr": "0x000d6ffffe9bf6e0",
            "type": "EndDevice",
            "networkAddress": 10345,
            "model": "E1766",
            "vendor": "IKEA",
            "description": "TRADFRI open/close remote",
            "friendly_name": "0x000d6ffffe9bf6e0",
            "manufacturerID": 4476,
            "manufacturerName": "IKEA of Sweden",
            "powerSource": "Battery",
            "modelID": "TRADFRI open/close remote",
            "hardwareVersion": 1,
            "softwareBuildID": "2.2.008",
            "dateCode": "20190410",
            "lastSeen": 1591961823167
        },
        {
            "ieeeAddr": "0xd0cf5efffe7ab117",
            "type": "EndDevice",
            "networkAddress": 723,
            "model": "E1757",
            "vendor": "IKEA",
            "description": "FYRTUR roller blind",
            "friendly_name": "0xd0cf5efffe7ab117",
            "manufacturerID": 4476,
            "manufacturerName": "IKEA of Sweden",
            "powerSource": "Battery",
            "modelID": "FYRTUR block-out roller blind",
            "hardwareVersion": 1,
            "softwareBuildID": "2.2.007",
            "dateCode": "20190311",
            "lastSeen": 1591962417767
        }
    ]
}

• After repairing, does the device work correctly?
• I don’t see the error in the provided log file, also the logging does not include the herdsman debug logging (which is only logged to STDOUT, not the log files!)

Flashed with the raspberry pi on the header and I got now ‘No network route’ (205)’ for my thermostats.
«`zigbee2mqtt:error 2019-10-30T13:48:22: Publish ‘set’ ‘system_mode’ to ‘thermostat/bathroom’ failed: ‘Error: Data request failed with error: ‘No network route’ (205)’
zigbee2mqtt:info 2019-10-30T13:48:22: MQTT publish: topic ‘zigbee2mqtt/bridge/log’, payload ‘{«type»:»zigbee_publish_error»,»message»:»Publish ‘set’ ‘system_mode’ to ‘thermostat/bathroom’ failed: ‘Error: Data request failed with error: ‘No network route’ (205)'»,»meta»:{«friendly_name»:»thermostat/bathroom»}}’

zigbee2mqtt:error 2019-10-30T13:53:48: Publish ‘set’ ‘system_mode’ to ‘thermostat/living_room’ failed: ‘Error: Data request failed with error: ‘No network route’ (205)’
zigbee2mqtt:info 2019-10-30T13:53:48: MQTT publish: topic ‘zigbee2mqtt/bridge/log’, payload ‘{«type»:»zigbee_publish_error»,»message»:»Publish ‘set’ ‘system_mode’ to ‘thermostat/living_room’ failed: ‘Error: Data request failed with error: ‘No network route’ (205)'»,»meta»:{«friendly_name»:»thermostat/living_room»}}’
«`

Ok I think the values are now corrupted. I reflashed now with sbl_tool.bin and cc_flash the version before: of the Z-Stack_Home_1.2 CC2531_SOURCE_ROUTING_20190619 archive.

But now all seems broken. No device is communicating with the coordinator. Is there a way to fix it?

try to re-power the thermostat so that the coordinator can find a new route to the device. If that doesn’t help try re-pairing them.

all devices are now not working with the old 20190619 and your firmware. I have flashed another CC2531 now. It does also not work.

so you say I have to repair all 20 devices without a reason?
no messages, the networkmap is also dead

edit:
pairing a fresh new device works. so maybe an id on the CC2531 has been changed and I can patch it?

If you didn’t change the panid, channel or network_key in configuration.yaml you shouldn’t have to do that. What errors do you get when controlling other devices?

I’ve got no data the most devices are sensors. Aquara PIR and Magnet sensors.
The new magnet fresh paired device work normal. All other devices are dead.
So I tried to re-pair the livingroom thermostat, firmware reset on the device itself. Then repair with the isolator and the device appears in the log, but now it will also throw the same exception.
zigbee2mqtt:info 2019-10-30T15:23:26: Zigbee: allowing new devices to join.
zigbee2mqtt:info 2019-10-30T15:23:26: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.6.0","commit":"78824b48c090470d178c00da80c0d57c58eeccf2","coordinator":{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20191028}},"log_level":"info","permit_join":true}'
zigbee2mqtt:info 2019-10-30T15:23:58: Accepting joining non-banned device '0x00158d000192309a'
zigbee2mqtt:error 2019-10-30T15:27:42: Publish 'set' 'system_mode' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'No network route' (205)'
zigbee2mqtt:info 2019-10-30T15:27:42: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'system_mode' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'No network route' (205)'","meta":{"friendly_name":"thermostat/living_room"}}'


I think I can purge the database.db and then It will work. I used jq and compared the new device with the old, it differs a bit, see screenshot.

0x00158d00032b747d is the »fresh« magnet sensor.

panid, channel or network_key are the same.

edit:
the ikea router has published their linkquality:
zigbee2mqtt:info 2019-10-30T15:30:15: MQTT publish: topic 'zigbee2mqtt/router/hall_ikea', payload '{"linkquality":52}'
still no output from other devices.

shall I upload the database.db without to getting a risk to publish secret informations about my keys?

@Koenkk I will now re-pair all devices. (done this 3 weeks ago). When I reflash the coordinator a repairing is always required?
edit: wow nice pairing works now by the first attempt without problems.

No repairing shouldnt be necessary when reflashing. Does your thermostat work now?

yes, but we have to wait for the next 1-2 days. I will check the logs for sporadic MAC transaction expired errors.

I think the problem is solved I found no new errors inside the container log.

@Koenkk
I’ve got the same issue from time to time. But I’m using a CC26X2R1 coordinator. Is it possible to decrease the poll rate for this coordinator, too?

I got again the MAC transaction error but only for 1-2 thermostats. Other thermostats working well. But sometimes after a long time, it will break things. Rebooting the zigbee2mqtt service helped yesterday. Today the same error. Changing the temperature on the thermostat itself fixed the issue (again).

➜ ~ docker logs addon_7ad98f9c_zigbee2mqtt_edge | grep -i ‘MAC transaction expired’

zigbee2mqtt:error 2019-12-29T12:21:23: Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
zigbee2mqtt:info  2019-12-29T12:21:23: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"thermostat/living_room"}}'
zigbee2mqtt:error 2019-12-29T12:22:01: Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
zigbee2mqtt:info  2019-12-29T12:22:01: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"thermostat/living_room"}}'
zigbee2mqtt:error 2019-12-29T12:23:47: Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
zigbee2mqtt:info  2019-12-29T12:23:47: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"thermostat/living_room"}}'
zigbee2mqtt:error 2019-12-29T12:25:04: Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
zigbee2mqtt:info  2019-12-29T12:25:04: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"thermostat/living_room"}}'

Which kind of data do you need to find out what is the issue now?

Same issue for me — I have 2 thermostats — one is working, second is presenting Mac transaction expired

gru 29 19:47:08 raspberrypi bash[6336]: zigbee2mqtt:debug 2019-12-29T18:47:08: Received MQTT message on 'zigbee2mqtt/termostat_gabinet/set' with data '{"current_heating_setpoint": 18.0}'
gru 29 19:47:08 raspberrypi bash[6336]: zigbee2mqtt:debug 2019-12-29T18:47:08: Publishing 'set' 'current_heating_setpoint' to 'termostat_gabinet'

What boders me is that this device is still anouncing itself. Any idea?
Also what is strange for me that I don’t have any readings about temperature from both devices

gru 29 19:47:37 raspberrypi bash[6336]: zigbee2mqtt:debug 2019-12-29T18:47:37: Publishing 'set' 'current_heating_setpoint' to 'termostat_sypialnia'
gru 29 19:47:44 raspberrypi bash[6336]: zigbee2mqtt:error 2019-12-29T18:47:44: Publish 'set' 'current_heating_setpoint' to 'termostat_sypialnia' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
gru 29 19:47:44 raspberrypi bash[6336]: zigbee2mqtt:info  2019-12-29T18:47:44: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'termostat_sypialnia' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"termostat_sypialnia"}}'
gru 29 19:48:02 raspberrypi bash[6336]: zigbee2mqtt:debug 2019-12-29T18:48:02: Device 'termostat_sypialnia' announced itself

My database.db here : https://pastebin.com/725ip5m5

after upgrade to zigbee2mqqt 1.8:

gru 29 20:26:41 raspberrypi bash[8767]: zigbee2mqtt:debug 2019-12-29 20:26:41: Received MQTT message on 'zigbee2mqtt/termostat_sypialnia/set' with data '{"current_heating_setpoint": 20.0}'
gru 29 20:26:41 raspberrypi bash[8767]: zigbee2mqtt:debug 2019-12-29 20:26:41: Publishing 'set' 'current_heating_setpoint' to 'termostat_sypialnia'
gru 29 20:26:41 raspberrypi bash[8767]: zigbee2mqtt:error 2019-12-29 20:26:41: Publish 'set' 'current_heating_setpoint' to 'termostat_sypialnia' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
gru 29 20:26:41 raspberrypi bash[8767]: zigbee2mqtt:debug 2019-12-29 20:26:41: Error: Data request failed with error: 'MAC transaction expired' (240)
gru 29 20:26:41 raspberrypi bash[8767]:     at ZStackAdapter. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:578:27)
gru 29 20:26:41 raspberrypi bash[8767]:     at Generator.next ()
gru 29 20:26:41 raspberrypi bash[8767]:     at fulfilled (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:5:58)
gru 29 20:26:41 raspberrypi bash[8767]: zigbee2mqtt:info  2019-12-29 20:26:41: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'termostat_sypialnia' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"termostat_sypialnia"}}'
gru 29 20:26:41 raspberrypi bash[8767]: zigbee2mqtt:debug 2019-12-29 20:26:41: Device 'termostat_sypialnia' announced itself

@sti0 can you try replacing /opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/startZnp.js with https://gist.github.com/Koenkk/ca4b55f33bb1727af6bda204b95feafe . This should set the poll rate to 200.

@Koenkk did this and there are no MAC-messages for a few days. Today I received one again.

Today I’ve got another issue zigbee2mqtt responses with the MAC error. After pressing the hardware buttons the new temperature setpoint is delivered to zigbee2mqtt and visible in HA. But if I then try to set the temperature with zigbee2mqtt the MAC error responses again.

For me fix with changing

@sti0 can you try replacing /opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/startZnp.js with https://gist.github.com/Koenkk/ca4b55f33bb1727af6bda204b95feafe . This should set the poll rate to 200.

@Koenkk did this and there are no MAC-messages for a few days. Today I received one again.

For me this fix doesn’t change anything. Is it possible that i have broken Spirit device ?
Even if i pair device i still get message that device announced itself, and also have this strange Mac error.
Second SPZB0001 works well.

sty 06 19:24:44 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:44: Starting interview of 'termostat_sypialnia'
sty 06 19:24:44 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:44: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"interview_started","meta":{"friendly_name":"termostat_sypialnia"}}'
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:24:46: Received Zigbee message from 'termostat_sypialnia', type 'readResponse', cluster 'genBasic', data '{"modelId":"SPZB0001","manufacturerName":"Eurotronic","powerSource":3}' from endpoint 1 with groupID 0
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:24:46: No converter available for 'SPZB0001' with cluster 'genBasic' and type 'readResponse' and data '{"modelId":"SPZB0001","manufacturerName":"Eurotronic","powerSource":3}'
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:24:46: Received Zigbee message from 'termostat_sypialnia', type 'readResponse', cluster 'genBasic', data '{"zclVersion":2,"appVersion":22,"stackVersion":5}' from endpoint 1 with groupID 0
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:24:46: No converter available for 'SPZB0001' with cluster 'genBasic' and type 'readResponse' and data '{"zclVersion":2,"appVersion":22,"stackVersion":5}'
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:24:46: Received Zigbee message from 'termostat_sypialnia', type 'readResponse', cluster 'genBasic', data '{"hwVersion":35,"dateCode":"20191014","swBuildId":"00000000"}' from endpoint 1 with groupID 0
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:24:46: No converter available for 'SPZB0001' with cluster 'genBasic' and type 'readResponse' and data '{"hwVersion":35,"dateCode":"20191014","swBuildId":"00000000"}'
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:46: Successfully interviewed 'termostat_sypialnia', device has successfully been paired
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:46: Device 'termostat_sypialnia' is supported, identified as: Eurotronic Spirit Zigbee wireless heater thermostat (SPZB0001)
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:46: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"pairing","message":"interview_successful","meta":{"friendly_name":"termostat_sypialnia","model":"SPZB0001","vendor":"Eurotronic","description":"Spirit Zigbee wireless heater thermostat","supported":true}}'
sty 06 19:24:46 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:46: Configuring 'termostat_sypialnia'
sty 06 19:24:48 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:24:48: Succesfully configured 'termostat_sypialnia'
sty 06 19:25:18 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:25:18: Device 'termostat_sypialnia' announced itself
sty 06 19:26:04 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:26:04: Device 'termostat_sypialnia' announced itself
sty 06 19:26:09 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:26:09: Device 'termostat_sypialnia' announced itself

sty 06 19:33:16 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:33:16: Device 'termostat_sypialnia' announced itself
sty 06 19:33:23 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:33:23: Received MQTT message on 'zigbee2mqtt/termostat_sypialnia/set' with data '{"current_heating_setpoint": 21.0}'
sty 06 19:33:23 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:33:23: Publishing 'set' 'current_heating_setpoint' to 'termostat_sypialnia'
sty 06 19:33:29 raspberrypi bash[6681]: zigbee2mqtt:error 2020-01-06 19:33:29: Publish 'set' 'current_heating_setpoint' to 'termostat_sypialnia' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
sty 06 19:33:29 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:33:29: Error: Data request failed with error: 'MAC transaction expired' (240)
sty 06 19:33:29 raspberrypi bash[6681]:     at ZStackAdapter. (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:578:27)
sty 06 19:33:29 raspberrypi bash[6681]:     at Generator.next ()
sty 06 19:33:29 raspberrypi bash[6681]:     at fulfilled (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:5:58)
sty 06 19:33:29 raspberrypi bash[6681]: zigbee2mqtt:info  2020-01-06 19:33:29: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'termostat_sypialnia' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"termostat_sypialnia"}}'
sty 06 19:33:35 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:33:35: Saving state to file /opt/zigbee2mqtt/data/state.json
sty 06 19:33:48 raspberrypi bash[6681]: zigbee2mqtt:debug 2020-01-06 19:33:48: Device 'termostat_sypialnia' announced itself

I’m looking for a solution too. We currently use three of these thermostats. We use a coordinator as CC2531 + router with external antenna. I’m not sure if I’m just getting it since the 1.8 update. But I installed two new devices yesterday. One is definitely not working…

zigbee2mqtt:info 2020-01-07 22:33:27: MQTT publish: topic 'zigbee2mqtt/Buero_HZ', payload '{"eurotronic_system_mode":1,"system_mode":"heat","linkquality":44,"local_temperature":20,"occupied_heating_setpoint":10,"unoccupied_heating_setpoint":16,"pi_heating_demand":0,"current_heating_setpoint":10,"eurotronic_error_status":0,"battery":100}'
zigbee2mqtt:error 2020-01-07 22:33:48: Publish 'set' 'current_heating_setpoint' to 'Buero_HZ' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'
zigbee2mqtt:info 2020-01-07 22:33:48: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'Buero_HZ' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)'","meta":{"friendly_name":"Buero_HZ"}}'

@PrivatHomeServer can You show log with debug on ?
Add in configuration

advanced:
  log_level: debug

I’m pretty sure that You will receive same issue as mine.

@Koenkk I’m still using your suggested change (https://github.com/Koenkk/zigbee-herdsman-converters/issues/715#issuecomment-565814660) and it’s not perfect but I noticed less MAC errors than without it. Would it be possible to set the poll rate by a parameter or would it be necessary to copy the changed startZnp.js file to my docker container after every restart?

I had to replace a thermostat (new) due to a hardware defect. Theoretically everything should work again. However, the thermostats cannot always be activated. It could be that my Zigbee network (linkquality) is not yet optimal. Maybe the thermostats do not always react.

If there is a version to flash again I can test this. So far it runs under:

_Version of Zigbee2Mqtt: 1.9.0
Coordinator version: 20190608_

@sti0 first i want to make sure this fixes the problem, can you change https://gist.github.com/Koenkk/ca4b55f33bb1727af6bda204b95feafe#file-startznp-js-poll-rate-200-L214 200 to 100 here and see if things improve?

I had this running for over a week on the stable z2m 1.9 version and the errors appear only sometimes (around 20 errors / week). I set the local_temperature_calibration all day so this is quite a good result.

I got the following errors:

zigbee_publish_error: Publish ‘set’ ‘local_temperature_calibration’ to ‘climate_schlafzimmer’ failed: ‘Error: Data request failed with error: ‘MAC transaction expired’ (240)’
zigbee_publish_error: Publish ‘set’ ‘local_temperature_calibration’ to ‘climate_schlafzimmer’ failed: ‘Error: Data request failed with error: ‘MAC no ack’ (233)’

THe errors appear on every of my three devices. Even there is an error, it «heals itself» and in the most cases not throw another error after.

This is not the perfect solution but way better than with a higher polling rate.

@sti0 you mean setting it twice right after each other fixes the issue?

I’m not running the modified pulling thing, but I have also noticed sometimes the TRV is slow to respond, poking it again immediately after the failure will work.

Maybe we give up to quickly? Or maybe it is in a deep sleep and needs a good kick or something.

@sti0 you mean setting it twice right after each other fixes the issue?

No, that’s not the case. Sometimes if you set a value twice the error appears two times. But it’s often the case that the second setting sets the value on the device (but the second setting could be a hour later). What I did ist to decrease the polling rate as you advised me (https://github.com/Koenkk/zigbee-herdsman-converters/issues/715#issuecomment-572426985).

@sjorge @sti0 if that indeed works, solving this issue would be as easy as just adding 240 here https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/zStackAdapter.ts#L647

If I understand the code, if we add 240, the command is resend after a MAC error. This could possibly work. I will test this. But should I increase the polling rate back to standard? Could we log the success somehow?

As mentioned in my previous post (https://github.com/Koenkk/zigbee-herdsman-converters/issues/715#issuecomment-578602851) there is also a 233 error sometimes:

zigbee_publish_error: Publish ‘set’ ‘local_temperature_calibration’ to ‘climate_schlafzimmer’ failed: ‘Error: Data request failed with error: ‘MAC no ack’ (233)’

@sti0

• yes change it back to the default
• if you don’t see an error in the log it works
• also try adding 233 there (let’s see if it improves)

@Koenkk ok, will do this at the weekend because I like to monitor the behavior.

@Koenkk added your suggestion and it seems to work fine but I received an 240 error last night (the 1st one since the wait adjustment). Do you have any other ideas?

I suggest to try up to 3 times (now 2), can you adapt the code (just duplicate the if statement for now).

Changed it into

const dataConfirm = await response.promise;
if (dataConfirm.payload.status !== 0) {
    if ([225, 233, 240].includes(dataConfirm.payload.status) && attempt === 0) {
        /**
         * When many commands at once are executed we can end up in a MAC channel access failure
         * error (225). This is because there is too much traffic on the network.
         * Retry this command once after a cooling down period.
         */
        await Wait(2000);
        return this.dataRequest(
            destinationAddress, destinationEndpoint, sourceEndpoint, clusterID, radius, data, timeout, 1
        );
    } else {
        if ([225, 233, 240].includes(dataConfirm.payload.status) && attempt === 1) {
            /**
             * When many commands at once are executed we can end up in a MAC channel access failure
             * error (225). This is because there is too much traffic on the network.
             * Retry this command once after a cooling down period.
             */
            await Wait(2000);
            return this.dataRequest(
                destinationAddress, destinationEndpoint, sourceEndpoint, clusterID, radius, data, timeout, 2
            );
        } else {
            throw new DataConfirmError(dataConfirm.payload.status);
        }
    }
}

Is this what you meant?

Thanks, I test it and will report.

@Koenkk another 240 error appeared with the changed version. I changed the wait time then to 2000ms but another error appeared.

Just wondering, is the stick you are using one that support the updateRoute thing? If not, Maybe the old route doesn’t work at that point and until the trv sends and update no new route is established.

~ sjorge

On 5 Feb 2020, at 23:20, Timo S. notifications@github.com wrote:


@Koenkk another 240 error appeared with the changed version. I changed the wait time then to 2000ms but another error appeared.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I’m using a CC26X1 (https://www.zigbee2mqtt.io/information/supported_adapters.html#texas-instruments-cc26x2r1) with the 20191106 firmware.

Nice, IIRC that does the new route discovery stuff… so I don’t think that could be an extra issue here, hmmmm

~ sjorge

On 5 Feb 2020, at 23:49, Timo S. notifications@github.com wrote:


I’m using a CC26X1 (https://www.zigbee2mqtt.io/information/supported_adapters.html#texas-instruments-cc26x2r1) with the 20191106 firmware.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I am having the same problem with only one of my devices (out of 5 total thermostats).

zigbee2mqtt:error 2020-02-08 12:07:13: Publish 'set' 'current_heating_setpoint' to 'office/thermostat' failed: 'Error: Write 0x00158d0001ffc5c5/1 hvacThermostat({"16387":{"value":800,"type":41}}, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":4151,"disableDefaultResponse":true}) failed (Error: Data request failed with error: 'MAC transaction expired' (240))'
zigbee2mqtt:info  2020-02-08 12:07:13: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'current_heating_setpoint' to 'office/thermostat' failed: 'Error: Write 0x00158d0001ffc5c5/1 hvacThermostat({"16387":{"value":800,"type":41}}, {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":4151,"disableDefaultResponse":true}) failed (Error: Data request failed with error: 'MAC transaction expired' (240))'","meta":{"friendly_name":"office/thermostat"}}'

Interestingly, the problematic device is very close (<1,5m clear line of sight) to my CC1352P-2 coordinator but I don’t know if that really matters :thinking:

Edit: also already tried repairing but the problem occurred again next day… I am virtually unable to control my device from HA/Z2M as it doesn’t react to any of the commands sent. It only works directly from the device. 🙄
Rebooted, deleted and re-paired again, and it seems to work now. Having this rtscts flag set to true now (can anyone explain to me what is does in this context?).

Interestingly, the problematic device is very close (<1,5m clear line of sight) to my CC1352P-2 coordinator but I don’t know if that really matters

My most affected device is only ~0.5m away from the coordinator. Even clear sight.

Okay, the error already appeared again (less than 24h). I cannot control my thermostat through Z2M … very annoying… :disappointed:

Any ideas for a potential fix for this? Anything I can test?

Okay, the error already appeared again (less than 24h). I cannot control my thermostat through Z2M … very annoying…

Any ideas for a potential fix for this? Anything I can test?

Could you please provide the firmware of the devices (https://github.com/Koenkk/zigbee2mqtt/issues/2500#issuecomment-583890805)

@Koenkk should we close the other issue (#2500) as it is duplicated?

@sti0 Sure, here they are:

{"model":"SPZB0001","friendly_name":"office/thermostat","manufacturerID":4151,"manufacturerName":"Eurotronic","powerSource":"Battery","modelID":"SPZB0001","hardwareVersion":35,"softwareBuildID":"22190930","dateCode":"20191014","lastSeen":1581282174965}

{"model":"SPZB0001","friendly_name":"living_room/thermostat","manufacturerID":4151,"manufacturerName":"Eurotronic","powerSource":"Battery","modelID":"SPZB0001","hardwareVersion":35,"softwareBuildID":"22190930","dateCode":"20191014","lastSeen":1581282409805}
{"model":"SPZB0001","friendly_name":"bedroom/thermostat","manufacturerID":4151,"manufacturerName":"Eurotronic","powerSource":"Battery","modelID":"SPZB0001","hardwareVersion":35,"softwareBuildID":"22190930","dateCode":"20191014","lastSeen":1581268977482}
{"model":"SPZB0001","friendly_name":"kitchen/thermostat","manufacturerID":4151,"manufacturerName":"Eurotronic","powerSource":"Battery","modelID":"SPZB0001","hardwareVersion":35,"softwareBuildID":"22190930","dateCode":"20191014","lastSeen":1581268979268}
{"model":"SPZB0001","friendly_name":"bathroom/thermostat","manufacturerID":4151,"manufacturerName":"Eurotronic","powerSource":"Battery","modelID":"SPZB0001","hardwareVersion":35,"softwareBuildID":"22190930","dateCode":"20191014","lastSeen":1581282313434}

As you can see, all have the same hw/sw version :thinking: The first one is the one having this issue (hope the others won’t be «infected» in the future :frowning: )

PS: I think closing the other issue is a good idea!

I’ve made the changes in: https://gist.github.com/Koenkk/c4bdd09dec17f69e4702bff87b24399b

@Koenkk running this for a week now and I’ve got <10 MAC errors so I think this implementation is way better than the actual state. I publish local_temperature_calibration all day long and change the temperature several times a day. So I think that’s a pretty good value (nothing is perfect ;-)).

I modified your gist and increased the attempts to 4 and wait time to 2000 sec. Maybe we could increase to 5 attempts and get rid of the other errors.

const dataConfirm = await response.promise;
        if (dataConfirm.payload.status !== 0) {
            if ([225, 233, 240].includes(dataConfirm.payload.status) && attempt <= 4) {
                /**
                 * When many commands at once are executed we can end up in a MAC channel access failure
                 * error (225). This is because there is too much traffic on the network.
                 * Retry this command once after a cooling down period.
                 */
                await Wait(2000);
                return this.dataRequest(
                    destinationAddress, destinationEndpoint, sourceEndpoint, clusterID, radius, data, timeout,
                    attempt + 1
                );
            } else {
                throw new DataConfirmError(dataConfirm.payload.status);
            }
        }

Surprisingly, mine started working again (no such errors yet/anymore) for no obvious reason! (Note that previously I was not even able to change the temperature via HA regardless of how often I tried…very mysterious 😅

@sti0 can you try changing it to 5? How many request did you do in total now? (want to calculate what percentage failed)

@Koenkk I will change it to 5 and will record the number of changes. I calibrate the temperature if room or thermostat temperature changes. So this could be very often every day.

Let me run this till Sunday and I will post the results.

@Koenkk after running this setup (https://gist.github.com/sti0/a7a5ff9825ba4476a0ffced53d3400e1) for 89h I received 2x MAC 233 and 2x MAC 240 errors. I executed commands 1093 times for all three devices (364.3 calls/device, ~4 calls/hour per device).

@sti0 big thanks for this, added!

@sti0 I’ve changed the code a bit, could you check if this causes some regression on your side? (try with latest dev branch).

@Koenkk will test this at the weekend.

@Koenkk is the change you mentioned already included in z2m 1.11.0 ?

@Koenkk OK, installed it today. I will report if there are any issues

I seem to have the same issue…
I’m running:

zigbee2mqtt:info  2020-03-27 10:23:11: Starting zigbee2mqtt version 1.7.1+dev (commit #ba18c5f773c160b54977908ed241cd40547a2fff)
zigbee2mqtt:info  2020-03-27 10:23:11: Starting zigbee-herdsman...
zigbee2mqtt:info  2020-03-27 10:23:12: zigbee-herdsman started
zigbee2mqtt:info  2020-03-27 10:23:12: Coordinator firmware version: '{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190619}}'

And this happens:

zigbee2mqtt:error 2020-03-27 10:23:20: Failed to configure '0x00158d0001cd2251', attempt 1 (Error: Data request failed with error: 'MAC transaction expired' (240)
    at ZStackAdapter.<anonymous> (/app/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:522:27)
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:5:58))

after reading through the posts, i’m not sure where to edit what to get it working again..

Thanks in advance!

First make sure you are on the latest zigbee2mqtt

First make sure you are on the latest zigbee2mqtt

I’m not able to update zigbee2mqtt (dev) to a version higher then my own version (1.7.1+dev)
and my coordinator version also seems up to date…

so not sure what to update to the latest? (should i use the none-dev version?)

1.7.1 is an old version, I would recommend to update to 1.12.0 or 1.12.0-dev.

By the way, my «‘MAC transaction expired’ (240))» errors seem to be gone, great!

By the way, my «‘MAC transaction expired’ (240))» errors seem to be gone, great!

Yes, I didn’t noticed these errors since a while. But I’m struggling with this one
error 2020-03-28 05:10:50: Publish 'set' 'local_temperature_calibration' to 'climate_schlafzimmer' failed: 'Error: Write 0x00158d0001ffc423/1 hvacThermostat({"localTemperatureCalibration":25}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":true}) failed (Error: AREQ - AF - dataConfirm after 5000ms)'

Only this device responses with this kind of error. Both other ones didn’t raised such an error. Don’t know if the device has a bad connection. It’s in the room next to the coordinator and there is one Hue bulb in this room. On the network map it is connected with the coordinator (CC26X2R1) instead the Hue bulb. Repairing and resetting doesn’t seem to help.

@sti0 very interessting, now that you mention this: I was having this (or at least a very similar?) error for a few days, too (but can’t find it in my logs anymore, may have deleted them already :-/ ). However, it disappeared from one day to another for no reason. It was very annoying since it didn’t allow me to control my device (except for using the device’s buttons directly of coz), like in your case, only happend with 1 out of 5 devices…

@sti0 can you try with this firmware:
znp_CC26X2R1_LAUNCHXL_tirtos_ccs_20200328.hex.zip

Thank you @Koenkk . This firmware works great. No error in the last 15h. The zigbee network seems to be more stable and it feels like motion sensors transmit signals faster. I will give you another feedback in the next few days.

Got this error again (z2m dev from yesterday, fw 20191106):

zigbee2mqtt:debug 2020-03-31 07:36:59: Publishing 'set' 'current_heating_setpoint' to 'office/thermostat'
zigbee2mqtt:error 2020-03-31 07:37:04: Publish 'set' 'current_heating_setpoint' to 'office/thermostat' failed: 'Error: Write 0x00158d0001ffc5c5/1 hvacThermostat({"16387":{"value":500,"type":41}}, {"timeout":6000,"manufacturerCode":4151,"disableDefaultResponse":true}) failed (Error: AREQ - AF - dataConfirm after 5000ms)'
zigbee2mqtt:debug 2020-03-31 07:37:04: Error: Write 0x00158d0001ffc5c5/1 hvacThermostat({"16387":{"value":500,"type":41}}, {"timeout":6000,"manufacturerCode":4151,"disableDefaultResponse":true}) failed (Error: AREQ - AF - dataConfirm after 5000ms)
    at Endpoint.<anonymous> (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:150:23)
    at Generator.throw (<anonymous>)
    at rejected (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65)

@Koenkk do you have a firmware for the CC1352-P to test as well?
Reflashing a firmware on this device still doesn’t require repairing (zigbee 3 stack), right? (It’s not mentioned here explicitly.) Sorry to ask (again) but I am bit branded on this topic… 😅

TL;DR: that works for me as well!

Honestly, this made me swet. First of all, flashing worked and the coordinator_backup.json was restored successfully, so no repairing necessary, puh!

What’s really interessing is that my device had the above error right before the firmware update. And before I updated, I restarted Z2M (just to try) which didn’t fix the error. I then upgraded with your given firmware and the error was immediately gone: I was able to set a new temperature which wasn’t possible with the old FW a few minutes ago, great! That thing seems to do the trick, thanks to @Koenkk ! Can you explain what you have changed in that new FW (basically)? Is this or will this become a «regular FW»? Asking because it’s not listed here yet.

Side note: When you get the following error while flashing a firmware (step 7):

Error! 
Unable to open file: C:/Users/a space in your path is bad/Downloads/znp_CC1352P_2_LAUNCHXL_tirtos_ccs_20200328/znp_CC1352P_2_LAUNCHXL_tirtos_ccs_20200328.hex

…make sure that there are no spaces in the path / file name (and maybe not too long) … wtf, come on, its 2020?! 😆

Good to hear, when this fw is well tested it will indeed become the regular. Will update changelog later.

I had some serious problems with the current firmware with paring Ikea tradfri devices, especially a bulp has never been paired. Good news: I used the firmware from above and now it works much better.

@Koenkk unfortunately, this is new (since I flashed the new FW):

zigbee2mqtt:debug 2020-04-03 22:42:44: Received MQTT message on 'zigbee2mqtt/living_room/couch_bulb/set' with data '{"state": "OFF"}'
zigbee2mqtt:debug 2020-04-03 22:42:44: Publishing 'set' 'state' to 'living_room/couch_bulb'
[...]
(node:715) UnhandledPromiseRejectionWarning: Error: Timeout - 62428 - 1 - 147 - 6 - 11 after 6000ms
    at Timeout._onTimeout (/app/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
    at listOnTimeout (internal/timers.js:531:17)
    at processTimers (internal/timers.js:475:7)
(node:715) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 9)
zigbee2mqtt:error 2020-04-03 22:42:54: Publish 'set' 'state' to 'living_room/couch_bulb' failed: 'Error: Command 0xf0d1b8000010421c/1 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))'
zigbee2mqtt:debug 2020-04-03 22:42:54: Error: Command 0xf0d1b8000010421c/1 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))
    at Endpoint.<anonymous> (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:339:23)
    at Generator.throw (<anonymous>)
    at rejected (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65)
zigbee2mqtt:info  2020-04-03 22:42:54: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'state' to 'living_room/couch_bulb' failed: 'Error: Command 0xf0d1b8000010421c/1 genOnOff.off({}, {"timeout":6000,"manufacturerCode":null,"disableDefaultResponse":false}) failed (Error: Data request failed with error: 'MAC channel access failure' (225))'","meta":{"friendly_name":"living_room/couch_bulb"}}'

Getting a lot of these errors (for different devices: bulbs, thermostats, and smart plugs) and my network is kinda laggy now. It went really well for a day or two … :thinking:

• Restarting Z2M didn’t help
• Reconnecting my CC1352P-2 solved it (for now?)

Once like always, please let me know if there’s more I can test or if you need more information!

Can’t confirm this for CC26X2R1 firmware. No errors since 5 days.

@codefinder2 could you provide a sniff when these errors happen?

Sure, will do and report here once the error occurs again!

Edit: didn’t happen again yet (~ ~9~ 14 days)…

Today I got this Promise Error, too. The whole network didn’t response. Restarting zigbee2mqtt didn’t solve the problem. Reconnecting the adapter while z2m is running didn’t solve this. I stopped z2m, reconnected the adapter and started z2m back up.

Somehow all logs before the first restart are deleted. Therefore I could not provide further information. (Did the rescue action with my smartphone…no lights in the whole house in the early morning 😨 )

Now the same thing happened to me.

As Koenkk said, please provide a sniff log if possible…

Which snifflog (Air, Serial, USB?) do you need and how to obtain it?

Hi,
I have the same issue since a long time. Today I discovered this discussion, while I was investigating it again.
Luckily, I could even reproduce it with wireshark trace if this can help anyone.

The wireshark and z2m logs are here :
zigbee_eurotronic_issue.zip

About sniffing in general, I made the wireshark capture with an nRF52840 usb dongle which is cheap, available and can be directly flashed with boot on usb, I used wireshark on windows and could even decrypt the Zigbee data with the network key. I could document the sniffing here if I can edit that, or someone could add it.

Now back to the issue, I could only note that the failing device is talking to the router not to the main coordinator directly, but could not really interpret all the communication.

error 2020-06-28 14:50:01: Publish ‘set’ ‘current_heating_setpoint’ to ‘living heat’ failed: ‘Error: Write 0x00158d000192dd3e/1 hvacThermostat({«16387»:{«value»:1100,»type»:41}}, {«timeout»:10000,»disableResponse»:false,»disableDefaultResponse»:true,»direction»:0,»srcEndpoint»:null,»reservedBits»:0,»manufacturerCode»:4151,»transactionSequenceNumber»:null}) failed (Error: Data request failed with error: ‘MAC transaction expired’ (240))’

addresses helper

• ‘living heat’ (Eurotronic) failing device

  • 0x00158d000192dd3e / 00:15:8d:00:01:92:dd:3e
  • 0x21f3 = 8691

• coordinator : ‘power lifo’

  • 0x00124b001d4a014b / 00:12:4b:00:1d:4a:01:4b
  • 0x0000

• router : ‘power router’

  • 0x00124b001c2f1279 / 00:12:4b:00:1c:2f:12:79
  • 0xd5b1 = 54705

• bathroom heat (Eurotronic) properly running device

  • 0x82f2= 33522

error time :
2020-06-28 14:50:01

Actually, even if I do reproduce the issue above, that is not actually directly the annoying issue I have but might be only related to it.
In my case, I can update the heat, but the thermostat and I see it updated on the device but I get no feed back. Which is annoying as I have a UI where the user would like to ensure the order was sent.

I just realized it’s actually the eurotronic that’s not sending the response with the failing device

reference device — working

• bedroom write success / feedback success :

  • <- DataRequest (17:05:25.426790)
  • -> WriteAttribute (17:05:25.437033)
  • <- WriteAttributeResponse (17:05:25.442254)
  • <- ReportAttributes (17:05:26.408171)

dut device — failing

• living heat write success but feedback fail :

  • <- DataRequest (17:08:30.778181)
  • -> WriteAttribute (17:08:30.788673)
  • <- WriteAttributesResponse (17:08:30.795426)
  • DUT keep sending lots of DataRequest but no WriteAttributeResponse

Maybe someone who reproduce the issue can say if they have the same behavior here of if this should be considered as a separate issue. Maybe not even an z2m one, rather Eurotronic ?

Sadly I can’t read your pcapng file in Wireshark.. Encapsulation type: Unknown (0)

I could only note that the failing device is talking to the router not to the main coordinator directly, but could not really interpret all the communication.

Just a hint for interpreting the communication:
You may also add column wpan.src16 and wpan.dst16 to your Wireshark view (right click table head -> Column Preferences -> Appearance -> Columns -> + -> Field=wpan.dst16), example here

This may help to follow through the routing:
You may see multiple lines with same Source/Destination/Info but different wpan adresses. These are the single routing-«hops». Source/Destination address is let’s say the full-way start/target address

For example: lets say device 0xaaaa sends to coordinator 0x0000 (source/destination), in wpan you will see that it in reality sent data first from 0xaaaa to its parent 0x0001, 0x0001 forwarded it to 0x0005, (…) 0x0005 to coordinator 0x0000.

I guess that the request (or its response) gets lost (or wrong routed)

@allofmex , thanks for the hints on viewing the traces. I did even put some colored filters for tx rx on short address 16 and long 64.
I also put all logs z2m and wireshark traces on a github repo special for the issue analysis (cases 1, 2, 3), hope you can get the pcap files, I redoanloded it from github and could still view it (of course either clone or download raw).
I’ll keep observing wireshark to better understand the behavior and I’m reading z2m code on the other hand.

hope you can get the pcap files

Sorry, still can’t read packets. Maybe custom encryption keys?

So you mean you could open the capture file in wireshark but only could not see the zigbee payload which is encrypted ?
I thought about the encryption key, then did not mention it as I’m using indeed the default security kee for demo and sharing purpose.

Now it could be that the wireshark dissector I’m using would have coded the data differently than your wireshark have opened them. I actually did not thought about that and expected the pcap file to be wireshark standard and not dissector specific.

For info I’m using this Sniffer. Github repo from Nordic. If that is the issue then it would make sense that I stick to the commonly used wireshark capture for sharing traces.

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

So I updated last week to the latest master and repaired the most of my devices. but the update had not solved the MAC transaction expired problem with my living room thermostat — all others are working well.

The living room and bathroom thermostats are still connected directly to my coordinator. This is strange I have a lot of Tradfri Ikea routers (signalverstärker) normally they should connect automatically to the router(s)?

Pressing a button on the thermostat will again fix/workaround the issue for a while.

@vansoest would you be able to sniff the traffic of both the working and non-working situation? This should give us more insight what the root cause of this problem is. (https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html)

Any solition? I have the same problem:

Zigbee2MQTT:error 2020-11-06 18:30:33: Publish 'set' 'system_mode' to '0x00158d00032f7f65' failed: 'Error: Write 0x00158d00032f7f65/1 hvacThermostat({"16392":{"value":33,"type":34}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Status 'INVALID_VALUE')'

Zigbee2MQTT:info  2020-11-06 18:30:33: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'system_mode' to '0x00158d00032f7f65' failed: 'Error: Write 0x00158d00032f7f65/1 hvacThermostat({"16392":{"value":33,"type":34}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4151,"transactionSequenceNumber":null}) failed (Status 'INVALID_VALUE')'","meta":{"friendly_name":"0x00158d00032f7f65"},"type":"zigbee_publish_error"}'

device: https://www.zigbee2mqtt.io/devices/SPZB0001.html

I fear I’m also experiencing the same issue.
Re-paring works for a bit and then stops, I believe it stops working after the next restart.
How do I change the polling rate in HassOS? or generally in Docker for that matter.
In the container, the path to the js file is
/zigbee2mqtt-1.16.1/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter
But surely enough, this doesn’t really help me since any changes will get overwritten as soon as i restart the container.

@Koenkk is there an option to reopen this thread? it seems that the issue is still present for a few of us
@vansoest any tips maybe from your side?

I cannot control two of three thermostats for a while now. I changed my Zigbee Coordinator for better performance to an «cc2652rb». So everything looks good (linkquality). I also added the value «debounce: 0.5». It looks like the effect to get every 10 sec the json information from each thermostat. But in the end i have now the problem to control the therostats. In the log file seem everything okey. Do you have an idea?

For me using «occupied_heating_setpoint» works fine, while «current_heating_setpoint» also gives me «MAC transaction expired» OR «invalid_value» errors.
I do not know what the difference between «occupied» and «current» exactly is, but using «occupied» fixed it for me.
Maybe this helps someone…

EDIT: Unfortunately only a temporary solution… a reboot of my raspberry broke it again. Now getting «MAC transaction expired» again for both «occupied» and «current»

@Koenkk Re-Opening of this issue would be highly appreciated

@M-Tier I think I can work around this.
First answering your question about current vs occupied. Only the current is effective for the temp regulation, the occupied and unoccupied are simply user configuration with the convenience of being able to be stored on the device, so that different automation software could pick it from there consistently. e.g. you have one tool to configure occupied/unoccupied and another tool for presence detection or schedule and swaps the current according to the value configured in occupied/unoccupied.
My impression is without an external tool using them, I did not notice any effect on the device itself in case you only care about the current.

Now back to the issue of this topic, how do I fix it every time,

• repair the device. Not fun, but you ought to be ready to repair every month or so, on the lucky case some devices run for more than a year, some others get lost after a week.
• repair is not easy, due to some mysterious bug I could never properly report (too complex), my z2m does not allow pairing devices neither old nor new ones, I even analyzed the wireshark traces and found an absurdity from z2m requesting the device to leave as soon as it gets first request, in order to workaround that, see next points :
• stop z2m, remove the zigbee adapter, wait 10 sec, re plug it, restart. This is even explained in z2m user guide, which to me shows the unexplained limitation, it is a firmware bug to me that might be hard to fix.
• remove the device before pairing it again
• keep the adapter as close as possible to allow proper attributes discovery

and now, if you want to have a happy long time using it without needing to repair again, most important is :

• keep your zigbee network clean
• make sure all your wifi routers are on a fixed freq far from the z2m zigbee freq
• keep checking signal quality (e.g. grafana below)
• ask your neighbors to stop using wifi

of course not all are possible so you might have to re-pair again when that error appear. Now of course as a product, it’s insane that a user has to live with such a pain, well don’t forget that the devices are not within their intended used scope so you have no official support here, we’re on our own. Standards are not enough to guarantee interoperability, reporting this bug to the device manufacturer might not interest them, and no one has the capability to debug the z2m firmware interoperability with each device.

long story short, hope the workaround I suggested help, for the time being I decided that living with the workaround will take me much less time than trying to fix them, here’s my projects github if you’d like to have more info about how I set up my heating system https://github.com/HomeSmartMesh/raspi

fileds|  
— | —
current_heating_setpoint |  
occupied_heating_setpoint |  
unoccupied_heating_setpoint |  
eurotronic_system_mode |  
pi_heating_demand |  
eurotronic_error_status |  
battery |  
linkquality |  
local_temperature |  

another funny example, in order to really understand the thermodynamics of your house, such grafana examples show the impact of opening a window. Note I have a scripts that uses window contact sensors and configures the off mode on the heating system

This is probably offtopic but now that I started exposing usage examples for the Eurotronics, I post this here two, maybe people googling about it would find it, I forgot to mention that monitoring the «pi_heating_demand» is probably the most important parameter because that’s where the money goes to, how much hot water flows in. In multiple cases, there is a flow passing although the temperature conditions do not require it, so that low maintenance could be cut. Also what we can see from the graphs below is that it might be a good idea to set the target temperature low even after the windows are closed in order to take advantage of heating up the air with the walls radiation, in other words, after closing the windows the temperature raises by itself to certain level even without heating, the pi heating demand taken at that time is kind of not needed / wasted, in this case not that high so does not matter much.

@wassfila
Thank you for the very detailed description of your workaround.
I will give that a try and keep you informed here, if I got any information on how to get it more stable.

I think I’m overseeing something, but the problem was somehow solved about 3 days ago, probably after an auto-update.
I’ve just spent some time going through the changelogs of
https://github.com/danielwelch/hassio-zigbee2mqtt
as well as the most recent ones of this repo and I couldn’t find any reason for the issue to go away. I’m just really happy it finally did.

I hope someone reads this at some points and can maybe enlighten me with the relevant change.
But even if not, my general thanks for everyone who works hard on this repo
I’ll make sure to update this message if the issue comes back at some point, but it has been around 3 days now and it seems solid.

@idofr thanks for the info, hope it’s fixed for you once and for all. I would not be that in a hurry to declare victory, because this issue has two folds, hidden mode, it can work fine for Months, then active mode where the issue can become noticeable, some times immediately after pairing some time after a long time.

Yes, I know, that’s also the reason I’ve waited a few days before posting an update here.
It seems though I was too quick to react. That HomeAssistantOS update to 5.8 has broken everything. I have 3 different plugins including zigbee2mqtt completely unusable at the moment

actually my main problem related to this issue was that I could not any any feedback from the devices and they stop reporting their attributes, this is now getting solved with a reconfigure, which does not require repairing.