Closed jjakob closed 5 years ago
did you define that message as to be polled? or did you use the HTTP port or the TCP port to life the message to being polled?
I think I've seen something that feels similar in https://github.com/john30/ebusd/issues/156:
the ebusd instance that initiates the bus read seems to receive about double the number of messages (two per forced read instead of one)
its visible in the ebusd logfile, too.
No, the configuration doesn't define it as polled:
ebusd-2.1.x/en/vaillant/ec.solsy.sc.csv:r,,Coll1Sensor,Collector1Sensor,,,,"0900",,,tempsensor,,,Temperature of COL1 sensor
So if I can somehow override this to be polled, I wouldn't need to use /get to poll the values. Is there a way to do this without external tools (like a custom config)?
during runtime, you can easily use "read -p ..." to set a message to being polled. If you want to change it permanently, you'd have to adjust the corresponding CSV entry though.
Thanks, I adjusted the CSV and now the messages are updated on mqtt without having to poll them via /get, so I'm not getting duplicates any more. However the original bug of duplicated messages when polling over /get is probably still unfixed. I'm using ebusd-3.1_amd64-stretch_mqtt1.deb. Also when polling using /get, every poll request gets a message response even if the value is unchanged, is this the intended behaviour?
yes, this is the desired behaviour since for an explicit /get or /set request is also supposed to produce an answer.
When polling for values using mqtt /get topic, for example:
And monitoring response using mosquitto_sub, sometimes a duplicate message with identical contents is received within 1-5 seconds of the initial response. Tested with publish & subscribe QoS both at 1 (the published /get messages don't get duplicated, the received value messages do). My initial hunch was on the QoS ebusd uses to publish messages (if it's 0) but I can't see a way to change it or what its default is.
The use-case is ebusd -> mosquitto -> telegraf -> InfluxDB, so any duplicate messages will use up valuable space. The polling is via a custom Go script that publishes the /get topics over mqtt.