Integration of Eqiva EQ-3 Radiator valve

[ma-ochoa]

This thermostatic radiator valves are taking great acceptance since they are quite functional and cheap.

The integrations for home assistant force to use the server's own bluetooth which has a limited range to control several valves in a house.

The valves do not report the current temperature but if they are able to close the radiator at a specified temperature, so in combination with a mijia-type ambient sensor they are perfect for controlling rooms.

There is already a mqtt integration for esp32 from which code could be reused

https://github.com/softypit/esp32_mqtt_eq3

[frnandu]

I would love this!
I'm using https://github.com/softypit/esp32_mqtt_eq3 on a separate esp32 to control my valves.

[kbedra-tbscg]

Thumbs up for that. This is the last device I need to integrate with my smart home.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rejoe2]

To get this device supported, according to this thread here, one has to just send time of day to the device. Unfortunately, I don't have exact info about the format... Response then should be returned a complete set of data from the device.
In general, a "send something as gtattool would do" command might be helpful (if sth. like that is possible). Perhaps this would also solve some problems like #540 or at least provide a way for "extended" debugging to users more familiar with gatttool?

(I'm not really familiar with that bt stuff, so that's more or less just a summary of impressions I got until now, might be wrong.)

[Torxgewinde]

Some small success: I figured out how to send the temperature setpoint to such a heating-valve:

##set to 30.0°C = ON (HEX value is 0x3C=60=2*30.0°C, 0x41 is a prefix)
mosquitto_pub -t "OpenMQTTGateway/commands/MQTTtoBT/config" -p 1883 -h server.lan -u "Nutzername" -P "passwort123" -m '{
  "ble_write_address":"AA:BB:CC:DD:EE:FF",
  "ble_write_service":"3e135142-654f-9090-134a-a6ff5bb77046",
  "ble_write_char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09",
  "ble_write_value":"413C",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }'

##set to 4.5°C = OFF (HEX value is 0x09=9=2*4.5°C, 0x41 is a prefix)
mosquitto_pub -t "OpenMQTTGateway/commands/MQTTtoBT/config" -p 1883 -h server.lan -u "Nutzername" -P "passwort123" -m '{
  "ble_write_address":"AA:BB:CC:DD:EE:FF",
  "ble_write_service":"3e135142-654f-9090-134a-a6ff5bb77046",
  "ble_write_char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09",
  "ble_write_value":"4109",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }'

##set to 5.5°C (HEX value is 0x0B=11=2*5.5°C, 0x41 is a prefix)
mosquitto_pub -t "OpenMQTTGateway/commands/MQTTtoBT/config" -p 1883 -h server.lan -u "Nutzername" -P "passwort123" -m '{
  "ble_write_address":"AA:BB:CC:DD:EE:FF",
  "ble_write_service":"3e135142-654f-9090-134a-a6ff5bb77046",
  "ble_write_char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09",
  "ble_write_value":"410B",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }'

[DigiH]

Some small success: I figured out how to send the temperature setpoint to such a heating-valve:

Nicely done @Torxgewinde!

Do you also see some freely broadcast advertising data from your EQ-3 Radiator valves, which could possibly be integrated into a decoder for Theengs Decoder, or are the values possibly only retrievable by READ or NOTIFY?

[Torxgewinde]

@DigiH: It does advertise its presence, but there is not a lot of info:

OpenMQTTGateway/BTtoMQTT/AABBCCDDEEFF {"id":"AA:BB:CC:DD:EE:FF","name":"CC-RT-BLE","rssi":-76}

with mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"pubadvdata":true}' the output is not much better:

OpenMQTTGateway/BTtoMQTT/AABBCCDDEEFF {"id":"AA:BB:CC:DD:EE:FF","mac_type":0,"adv_type":0,"name":"CC-RT-BLE","manufacturerdata":"0000000000000000000000","rssi":-69}

Info must be retrieved by "subscribing". For example I had a sketch, that queries the valve mode (Auto, Manual). Here is the relevant part:

NimBLEClient *pClientValve = NimBLEDevice::createClient();
  BLEAddress ValveAddress("AA:BB:CC:DD:EE:FF");

  if (heating != LEAVEIT && pClientValve->connect(ValveAddress)) {
    NimBLERemoteService *pService = pClientValve->getService("3e135142-654f-9090-134a-a6ff5bb77046");
                
    if (pService != nullptr) {
      NimBLERemoteCharacteristic *notifyCharacteristic = pService->getCharacteristic("d0e8434d-cd29-0996-af41-6c90f4e0eb2a");
                    
      if (notifyCharacteristic != nullptr) {
        Serial.printf("Valve: Register for notify (RSSI: %d)\r\n", pClientValve->getRssi());
        
        notifyCharacteristic->subscribe(true, [&valveState, &busyValve](
          BLERemoteCharacteristic* pBLERemoteCharacteristic,
          uint8_t* pData,
          size_t length,
          bool isNotify) {
            char stateChr = pData[2] & 0x0f;
            switch (stateChr) {
              case 0x08:
                Serial.printf("Valve Mode is: Auto\r\n");
                break;
              case 0x09:
                Serial.printf("Valve Mode is: Manual\r\n");
                break;
              default:
                Serial.printf("Valve Mode is: Unknown\r\n");
             ;
           }
...

What I am missing in OMG is a subscribe option, I only see "write" and "read".

BTW: I am not sure if it relevant, but if anything fails for others: I did not use the corresponding manufacturer App for years, thus the firmware has not been upgraded. I hope nothing changed to perhaps more recent valves/firmware.

[DigiH]

Shame about no valuable advertising data, with
"manufacturerdata":"0000000000000000000000"
I'm actually wondering if there is an option in the app which allows for the manufacturerdata to contain encoded information.

Correct, OpenMQTTGateway only allows to READ or WRITE, but not for NOTIFY options. If and how that might be implemented in the future, I do not know.

[Torxgewinde]

There is a VERY detailed description of the protocol for these valves at https://reverse-engineering-ble-devices.readthedocs.io/en/latest/protocol_description/00_protocol_description.html

Setting the mode to manual works:

##set Manual Mode
# byte 0: 40
# byte 1: 40
mosquitto_pub -t "OpenMQTTGateway/commands/MQTTtoBT/config" -p 1883 -h server.lan -u "Nutzername" -P "passwort123" -m '{
  "ble_write_address":"00:11:22:33:44:55",
  "ble_write_service":"3e135142-654f-9090-134a-a6ff5bb77046",
  "ble_write_char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09",
  "ble_write_value":"4040",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }'

Setting the time still contains some issue, but perhaps someone can spot and fix it:

##set date and time
#byte 0: 03
#byte 1: year % 100
#byte 2: month
#byte 3: day
#byte 4: hour
#byte 5: minutes
#byte 6: seconds

echo "Byte 0: 03"

eval $(echo -e "$(date '+YEAR=%y\nMONTH=%m\nDAY=%d\nHOUR=%H\nMINUTE=%M\nSECOND=%S')")
echo $YEAR
eval "$(printf 'YEAR_HEX=%02x' $YEAR)"
echo "Byte 1: $YEAR_HEX"

echo $MONTH
eval "$(printf 'MONTH_HEX=%02x' $MONTH)"
echo "Byte 2: $MONTH_HEX"

echo $DAY
eval "$(printf 'DAY_HEX=%02x' $DAY)"
echo "Byte 3: $DAY_HEX"

echo $HOUR
eval "$(printf 'HOUR_HEX=%02x' $HOUR)"
echo "Byte 4: $HOUR_HEX"

echo $MINUTE
eval "$(printf 'MINUTE_HEX=%02x' $MINUTE)"
echo "Byte 5: $MINUTE_HEX"

echo $SECOND
eval "$(printf 'SECOND_HEX=%02x' $SECOND)"
echo "Byte 6: $SECOND_HEX"

echo "COMMAND: 03${YEAR_HEX}${MONTH_HEX}${DAY_HEX}${HOUR_HEX}${MINUTE_HEX}${SECOND_HEX}"

mosquitto_pub -t "OpenMQTTGateway/commands/MQTTtoBT/config" -p 1883 -h server.lan -u "Nutzername" -P "passwort123" -m '{
  "ble_write_address":"00:11:22:33:44:55",
  "ble_write_service":"3e135142-654f-9090-134a-a6ff5bb77046",
  "ble_write_char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09",
  "ble_write_value":"03$YEAR_HEX$MONTH_HEX$DAY_HEX$HOUR_HEX$MINUTE_HEX$SECOND_HEX",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }'

[ChrisPallasch]

Gab es hier irgentwelche Fortschritte?

In Ermangelung von gefundener entsprechender Dokumentation wie die Device-Definition beim Theengs-Dekoder zu verstehen ist, tue ich mir da etwas schwer. Zum EQ-3 selbst finde man ja gute Dokumentation.

Soweit ich es glaube verstanden zu haben, muss man den EQ-3 erst triggern, bevor er gesprächig wird, was ich jedoch beim decoder nicht fand.

Gruss von der Ostsee
Chris

[ChrisPallasch]

Vielleicht kann mir jemand ja mal folgenden Passus etwas erklären

"condition":["manufacturerdata", "=", 50, "index", 0, "4c000215655f83caae16a10a702e31f30d58dd82"],
   "properties":{
      "batt":{
         "decoder":["value_from_hex_data", "manufacturerdata", 48, 2, false]

Was/Wo ist 50?
Was sagt index 0
Wo beginnt "4c00...."

[DigiH]

Vielleicht kann mir jemand ja mal folgenden Passus etwas erklären

English please, so everybody can follow and join in if desired.

Was/Wo ist 50?
Was sagt index 0
Wo beginnt "4c00...."

All the decoder details are explained in the Theengs Decoder section at

https://decoder.theengs.io/participate/adding-decoders.html

To understand and see which raw advertising data devices sent out, which are then decoded by the individual decoders you can also set Advertisement and Advanced Data to true.

The initial issue EQ-3 radiator valve is not included in any decoder, as its properties can only be fetched by connection and they are not being broadcast through the advertising data. So any property can only be gotten by manual READ commands with OpenMQTTGateway, and any command needs to be issued by an OpenMQTTGateway WRITE command.

[ChrisPallasch]

Oops, please excuse, I had been at a german forum for a while and therefor mistankinly continued to write german.

Thank you very much for the two links, they seam to be very helpful.

The last paragraph explains why I cant find characteristics as shown in several documents, thx
Guess I'll switch to an other ble device for further testing.

Hope it will be easier/better with the cheap health-watch I ordered a few days ago...

Chris

[ChrisPallasch]

How can I get so called known characteristics, like Battery-Level (0x2A19)?
At rRF Connect it seams the value is activly read and not included within an array.
Here it's "00002a19-0000-1000-8000-00805f9b34fb".
I cant see the returned value of "4B" (75%)
Is that the same as with EQ-3 and cant be done directly in the theengs device header?

Is a mqtt read command the only solution?
mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT -m '{
"ble_read_address":"AA:BB:CC:DD:EE:FF",
"ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb",
"ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb",
"value_type":"STRING",
"ttl": 4 }'

Chris

[DigiH]

Theengs Decoder is designed to only receive and decode freely broadcast advertisement data. If you do find any useful advertisement data for the EQ-3 valves, please let us know.

To connect and READ (or WRITE) any service/chars you can use the OpenMQTTGateway READ/WRITE commands. This won't however work with any Notifications yet.

The standard battery service should be possible, as I also use it to get some of my devices' battery level. The same for any other READable/WRITEable service/chars, which are usually also marked as such in nRFConnect.

Just posted my reply when you updated yours ;)

Is a mqtt read command the only solution?

Yes it is, as this is also how any other such EQ-3 valve solutions do it, but the service needs to be different to the characteristic, and for the type try HEX or INT. e.g. for the standard battery level it is

…
"ble_read_service":"0000180f-0000-1000-8000-00805f9b34fb",
"ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb",
"value_type":"HEX",
…

[ChrisPallasch]

Thank you very much!
I start to understand it :-)

[ChrisPallasch]

Might it be, that I need to define a device inkl "tag" or otherwise the command wont get send at all?
I so far cant find an answer json with MQTT broker or at the logs.

[DigiH]

How are you actually sending the command - by the Mosquitto CLI command, through the MQTT Explorer Publish section …?

A very popular problem when starting with READ/WRITE commands is to use the given OpenMQTTGateway place-holder name in the topic of the examples, while for an actual command to your gateway this needs to be the actual name of your gateway ;)

If you use MQTT Explorer, or any other MQTT monitoring, you will then also see the commands sub-topic when commands arrive at the gateway.

[ChrisPallasch]

In fact I tried both, aswell my settings as compiled, aswell as (cause there might be some hardcoding) the default OMG Topic. Both can be seen at mosquitto-log/MQTT Explorer and ioBroker --- but no where an anser.

You said you do use Battery-Level.
Are those of your devices - at least basically - defined at Theengs Decoder?

[DigiH]

You said you do use Battery-Level.
Are those of your devices - at least basically - defined at Theengs Decoder?

No, they do not broadcast any valuable advertising data either, so they are not included in Theengs Decoder.

Could the EQ-3 valves be of "mac_type": 1 by any chance? Then this would need to be included in any READ/WRITE command to succeed, as described in the TIP paragraph of the READ/WRITE section.

You can see if they are by setting Advertisement and advanced data to true.

Either way, I do recommend getting MQTT Explorer for any MQTT trials and a good overview of published messages and commands.

[DigiH]

And I assume you are using the latest OpenMQTTGateway 1.7.0 release, correct?

[ChrisPallasch]

The source I downloaded from github says 1.6.0 (for the zip)

[DigiH]

Ahh, AFAIK the MQTTtoBT READ/WRITE command structure has changed since then, which is what you are seeing in the current docs, for the latest 1.7.0 release, while the previous READ/WRITE commands were

https://github.com/1technophile/OpenMQTTGateway/blob/b806ea93549bd2f2d8bbdec043a1c5fbd6e5e9d4/docs/use/ble.md#readwrite-ble-characteristics-over-mqtt

So what do you get with this?

mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config 
…

[ChrisPallasch]

thats one of the paths/topics I tried

I'll later compile the "OMG-development" (using default settings), maybe things then change...

[DigiH]

And please also do get MQTT Explorer, to then easily make screenshots with commands in the Publish section and received commands and messages on the left for your gateway.

Makes pinning down any remaining issues a lot easier and quicker :)

[ChrisPallasch]

I'm more and more into Christmas preparation inkl trip to family between the years.
Guess I'll be back new year
Have a happy christmas :-)

[DigiH]

Auch frohe Weihnachten an dich und deine Familie :)