Corner case with HORA valves (A5-20-04) and MQTT

Begonnen von tomaszG, 17 Dezember 2020, 14:42:18

Vorheriges Thema - Nächstes Thema

tomaszG

Hello,

I work with HORA valves (profile A5-20-04) and I am using an MQTT bridge to forward its measurements to a broker hosted on a server.
It is working fine 98% of time but we have a recurring issue that I will try to describe. First the excerpt of the relevant part of the fhem config


define TCM_ESP3_0 TCM ESP3 /dev/ttyUSB0@57600
setuuid TCM_ESP3_0 5f759d74-f33f-eac7-e3b8-f51d07e93d40043b
attr TCM_ESP3_0 sendInterval 0
attr TCM_ESP3_0 smartAckMailboxMax 0


define mqttGeneric MQTT_GENERIC_BRIDGE mqtt subType=hvac.06|hvac.04|tempSensor.17|tempSensor.14|lightSen$
setuuid mqttGeneric 5f759d74-f33f-eac7-894c-d9ee4174b07acf5b
attr mqttGeneric IODev locmqtt
attr mqttGeneric globalDefaults base={"enocean/$device"}
attr mqttGeneric globalPublish *:topic={"$base/$reading"}

define locmqtt MQTT2_CLIENT our.server.ch:8053
setuuid locmqtt 5f759df0-f33f-eac7-1437-576e7a58dcdbc24e
attr locmqtt SSL 1
attr locmqtt clientId rpbel008
attr locmqtt subscriptions cmd/#

define EnO_01A64FB0 EnOcean 01A64FB0
setuuid EnO_01A64FB0 5fbfa5d9-f33f-0ff2-6484-0425b68a9ef7a05c
attr EnO_01A64FB0 IODev TCM_ESP3_0
attr EnO_01A64FB0 comMode biDir
attr EnO_01A64FB0 destinationID unicast
attr EnO_01A64FB0 eep A5-20-04
attr EnO_01A64FB0 manufID 045
attr EnO_01A64FB0 room EnOcean
attr EnO_01A64FB0 subDef FF91D981
attr EnO_01A64FB0 subType hvac.04
attr EnO_01A64FB0 teachMethod 4BS
attr EnO_01A64FB0 webCmd setpointTemp


It sometimes happens that a valve enters a strange (fault?) mode, where it starts to report (at least apparently in FHEM) a measured temperature of 10.7C precisely ( see picture attached). We have tried for a while to find out why this happens but could not so far. It seems the valve is still functional (at least after rebooting completely). The more problematic part is that then we observe a strange behaviour in FHEM where the valve is labelled as in processing and updates the calculated setpoint very fast instead of once per minute (we end up with 10'000s of points per day or more). The updates are forwarded through MQTT which clogs the MQTT broker which is not able to deal with so many messages... This means all data forwarded on this broker is affected with lost data ( not only this particular valve). Currently, the only solution I have is to delete the valve from FHEM, which is not really convenient...

Any help to find what's going on, or find a fix, even if temporary is welcome. Thanks

Tomasz


Beta-User

Not familiar with that EnOcean stuff, but imo the MQTT part looks ok.

Perhaps you try to avoid mass messages by adding appropriate settings to attributes "event-on-change-reading" and "event-min-interval"?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

When the problem is "active", I would set "attr global verbose 5" for a short time, to see more exactly, where the source of the problem is: the FHEM framework, the EnOcean module, or the EnOcean controller. If the latter, a "set TCM_ESP3_0 reset" might help, this could be even issued automatically, triggered by a sequence

tomaszG

Hello,

I take good note of these suggestions, I think that is helpful. We managed to pinpoint that this seems to happen when two controllers are trying to talk to the same valve. I can't really explain why, but the side effects include the FHEM fields to change very quickly. We now know how to identify and correct that on the valve side but I believe the problem remains in FHEM, and I may be able to diagnose it better if it appears again.