I am trying to integrate EQ3 Bluetooth TRV with openHab.
I have setup a tasmota ESP32 device with BLE enabled to connect to EQ3 valves.
But the implementation in tasmota uses MQTT topics like stat/<TasmotaDevice>/EQ3/<EQMACADD> to get the status, which returns a json string with all relevant information (setpoint temperature, opening of valve, etc).
For setting temperature, for example, you use cmnd/<TasmotaDevice>/EQ3/<EQMACADD>/settemp <tempval>" using just raw values.
When you send a command to the valve to set one value, it returns the complete set of values in the “stat” topic with the complete JSON set of values and containing error info.
I can get the values from eq3 valves in just one channel retrieving the status JSON value.
Then I can link items to it an use JSONPATH to extract the values from it.
But then I cannot change that values, as there is no place to introduce the comand MQTT topics.
You can use different channels for each value, giving different topics to get the value and set it.
But it seems quite inefective, as the valve will answer with the complete JSON with all the values of the status of the valve, from where you have to use JSONPATH to extract each value.
Doing it multiple times seems a waste of resources.
How is the best way to interact with this kind of devices?
The target only responds once to one command; all the channels linked to the same topic update their individual Items with the up-to-date information contained in the one message.
Thanks for answering so fast.
May be, I am quite new to openHAB. I don’t know the indepths of it.
I am not sure to understand your answer.
The valve will respond for each command but not with just the result or the set value.
It respond with the complete status fo the valve (and you have to extract the info with JSONPATH to see if it did it correctly).
If I understand you well, you say that the best way is just to create separate channels for each value and stablish a JSONPAT to extract the value. (it will have to retrieve the status several times to get al values and extract the value from the answer).
Yes, that is a Good Thing giving you all the up-to-date information.
Yes.
There is only one incoming message, there is no harm in getting all the information out of it, it is all already there whether you use it or not. It is not even possible to set up a channel that only looks at some of the incoming messages on its topic, but not others.
We have no control over that from the openHAB end. Look at Tasmota if you want something to change there.
You’re going to get some message packet either way. Whether the payload is 12 bytes or 50 bytes makes very little difference to the network overheads.
I have to ask to tasmota team if there is an implementation of homeassistant protocol for the valves.
Even if I enable homeassistant the valves continue presenting their data in that sort of “propietary” format.
Thank you a lot. It is great knowing I am not doing it the usual way.
You have saved me a lot of time trying to find a solution to what seems to be really no a problem.
With mine each TRV sends its own topic
stat/EQ3/001A22126545
and I get this JSON from a TRV
{“cmd”:“poll”,“result”:“ok”,“MAC”:“001A22126545”,“tas”:“UtilityESP32-1876”,“RSSI”:-77,“stattime”:1639330288,“temp”:10.5,“posn”:11,“mode”:“manual”,“hassmode”:“heat”,“boost”:“inactive”,“dst”:“set”,“window”:“closed”,“state”:“unlocked”,“battery”:“GOOD”,“holidayend”:“00-00-00 00:00”}
I have a Thing called Radiators
For the SetPoint I create a Channel UtilitySet which gives a Channel mqtt:topic:MQTTv2:Radiators:UtilitySet
the State field is
stat/EQ3/001A22126545
and in Advanced
JSONPATH:$.temp
The Command is
cmnd/UtilityESP32/EQ3/001A22126545/settemp
You can then Link the Channel to an Item (I still create my items in an .items file) so that it an be used in sitemaps etc.
You can repeat the procedure for each parameter/valve
Yes, thank you, mine too, one state topic for each valve.
I had expected that each field there (mode, temp,… ) was a separate topic when you activated HOMEASSISTANT autodiscovering.
The topic commands are separated, one for each field. It was strange for me, but I have seen that is quite a usual behaviour: composing a JSON message with the state containing all the fields, and a separate command topic for each thing you can control, When you change something it answers with the whole status.
I have done as you say: use the state topic and JSONPATH to get the value and the cmnd topic to set it.
But it dos not work correctly if you use a channel fro temp defined as mqtt:number (as it should be in theory as it is a number what you receive and not a string). Only works if you define it as mqtt:string.
