ecowitt2mqtt: Upgrading to 2023.11.0 Breaks Publishing

Describe the bug It appears that after upgrading from 2023.08.0 to 2023.11.0, MQTT publishing stopped working. Downgrading to 2023.08.0 restores previous behavior.

To Reproduce

verbose: false
precision: 2
gateways:
  # GW2000B
  42B109437ED4E644FFF2DF549A1A0DAB:
    hass_entity_id_prefix: ecowitt_gw2000b
  # GW1100B
  55585D938764215B37D52CA7AD96E8F9:
    hass_entity_id_prefix: ecowitt_gw1100b

Environment variables:

  - name: ECOWITT2MQTT_MQTT_BROKER
    value: mqtt
  - name: ECOWITT2MQTT_MQTT_PORT
    value: "1883"
  - name: ECOWITT2MQTT_HASS_DISCOVERY
    value: "true"
  - name: ECOWITT2MQTT_PORT
    value: "8080"
  - name: ECOWITT2MQTT_CONFIG
    value: /config.yaml

Expected behavior

MQTT messages continue to publish.

Additional context

Logs similar to the following can be found:

2023-11-05 16:50:28,652 | WARNING | There are 444 pending publish calls.

ecowitt2mqtt.log

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Reactions: 2
  • Comments: 59 (53 by maintainers)

Most upvoted comments

Out of curiosity, has your current pr-777 image continued to run okay?

Yes, but I didn’t yet restart HA. 😃

I saw the retain flag on config topics, I think you can release it.

Pulled it now. Will test and report back.

Deployed ghcr.io/bachya/ecowitt2mqtt@sha256:cdc9ad7bef62b50c3504eafdacf8f62ca2a5bba7aedb8025d2be60a55d8df1b2 to my cluster. Will report any issues!

Already pulled the new one 2 minutes ago. Will keep you posted

Checking in: any news?

Yes, bad news: happened 11h ago. But I got the log this time (from journald), it stopped at 14.17.00, I cut the log from 14.10.00 to 14.30.00. Find it attached, hope it helps.

ecowitt2mqtt-log.zip

That’s up to your Docker configuration: https://sematext.com/blog/docker-logs-location/

it’s journald. unfortunately it rotated, last event was 5-6h AFTER the issue that caused the unavailability.

Meanwhile I’m very tempted to turn retain on again…

BTW: sematext is interesting…will check it tomorrow. Thanks.

Okay, I think #777 should fix this. @alexdelprete and @Silvenga, if you are Docker users, I’d appreciate your testing once the images build (you’ll be able to pull ghcr.io/bachya/ecowitt2mqtt:pr-777).

Sorry for the delay Aaron, just installed pr-777, I disabled retain and also deleted all existing topics in the broker so to start in a clean state.

It’s working for now, I’ll monitor it and let you know how it behaves.

  1. ecowitt2mqtt reconnects.
  2. Another payload arrives. Because ecowitt2mqtt has been running this whole time, it sees this payload and says, “I’ve already published config info for these entities, so I won’t do it again.” This means that it fails to republish the config topic.

So, although retain is a bit more than a workaround (broaching “reasonable solution”), I don’t want to force a personal configuration on every user. To address this, I need to republish the config topic when an MQTT broker reconnect happens.

On connect/reconnect it is mandatory that config has to be republished. You can’t assume config is retained

In any case, I think for this use-case retain is the best configuration, if the broker supports it.

Okay, I think #777 should fix this. @alexdelprete and @Silvenga, if you are Docker users, I’d appreciate your testing once the images build (you’ll be able to pull ghcr.io/bachya/ecowitt2mqtt:pr-777).

Sorry @bachya, been away. I just deployed 2023.11.1 to my cluster and it looks much happier - I’m seeing updates published at the expected interval - no more pending calls warning messages. (😹 Woot! Thanks!)

I’ll continue to monitor for behavior that @alexdelprete reported.

Thanks, @alexdelprete. That definitely is a bug (and may be the real issue, vs. the pending calls warnings).

Yep!

bachya/ecowitt2mqtt:2023.11.0