zigbee-herdsman-converters: 'MAC transaction expired' (240) with Eurotronic Spirit SPZB0001 thermostat

Sporadic my Eurotronic Spirit SPZB0001 thermostat will not react on commands and throw an exception 'MAC transaction expired’ like: zigbee2mqtt:error 2019-10-25T10:07:50: Publish 'set' 'current_heating_setpoint' to 'thermostat/living_room' failed: 'Error: Data request failed with error: 'MAC transaction expired' (240)' zigbee2mqtt:info 2019-10-25T10:07:50: 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"}}'

But If I change the temperature manually on the device itself, the transaction error will be fixed and reacting normal on set current_heating_setpoint: zigbee2mqtt:info 2019-10-25T10:19:56: MQTT publish: topic 'zigbee2mqtt/thermostat/living_room', payload '{"eurotronic_error_status":0,"current_heating_setpoint":19,"local_temperature":19.28,"occupied_heating_setpoint":20,"unoccupied_heating_setpoint":16,"eurotronic_system_mode":1,"pi_heating_demand":0,"battery":100,"linkquality":73,"system_mode":"heat"}'

using hassio with zigbee2mqtt-edge docker image, but can not get the current git commit: https://github.com/danielwelch/hassio-zigbee2mqtt/issues/242 my latest version I assume is a few days old but already patched with the thermostat_system_mode feature! https://github.com/Koenkk/zigbee-herdsman-converters/pull/682 Coordinator: CC2531 zStack12 20190619

How to avoid this problem? The thermostat device is in the same room with the coordinator. The networkmap shows me a value from the coordinator to the device around 80-120.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 116 (71 by maintainers)

Commits related to this issue

Most upvoted comments

@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 |

image

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

image

@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?

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

@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.

@sti0 big thanks for this, added!

@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.

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