emsesp / EMS-ESP

ESP8266 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
300 stars 96 forks source link

(v2) normalize command infrastructure for devices (mqtt & console) #445

Closed proddy closed 3 years ago

proddy commented 3 years ago

The MQTT commands inherited from v1.9 and the new Console commands are not always in sync. The code needs some refactoring and simplification. This will also help reduce the memory hog when running mqtt, telnet, and web at the same time on an ESP8266.

Specification

1) sending commands to EMS-ESP is done by a single topic called cmd. The payload determines the device/sub-system and the action. An additional id field can be used to set the heating circuit. For example:

This will simplify the code significantly. When using a console command it will just invoke the MQTT function effectively simulating an incoming MQTT request. It will mean each command function will take now a char * and be responsible for deciphering the values from the payload string. For example the setcomfort() function will no longer an int values 1, 2 or 3 but "hot", "eco", "intelligent".

4) The WebUI will be used for configuring EMS-ESP. The console will have a few set commands for debugging mainly such as setting the wifi credentials or changing the UART tx mode

FredericMa commented 3 years ago

Yes, indeed, I don't see those. So never missed them until now that I know 😄 This is the output of the show command:

Boiler: HT3 (DeviceID:0x08, ProductID:95, Version:23.04)
  Hot tap water: off
  Central heating: off
  Warm Water activated: on
  Warm Water charging type: 3-way valve
  Warm Water circulation pump available: off
  Warm Water circulation pump freq: 1x3min
  Warm Water circulation active: off
  Warm Water comfort setting: Hot
  Warm Water disinfection temperature: 75°C
  Warm Water selected temperature: 50°C
  Warm Water set temperature: 50°C
  Warm Water current temperature (intern): 64.7°C
  Warm Water current temperature (extern): 64.7°C
  Warm Water current tap water flow: 0.0l/min
  Warm Water # starts: 802
  Warm Water active time: 12 days 11 hours 32 minutes
  Warm Water charging: off
  Warm Water disinfecting: off
  Selected flow temperature: 0°C
  Current flow temperature: 29.5°C
  Gas: off
  Boiler pump: off
  Fan: off
  Ignition: off
  Burner selected max power: 100%
  Burner current power: 0%
  System service code:  (0)
  Heating temperature setting on the boiler: 66°C
  Boiler circuit pump modulation max power: 100%
  Boiler circuit pump modulation min power: 10%
  Boiler circuit pump delay time: 3min
  Boiler temp hysteresis on: -5°C
  Boiler temp hysteresis off: 0°C
  Boiler burner min period: 3min
  Boiler burner min power: 0%
  Boiler burner max power: 100%
  Outside temperature: 25.7°C
  Pump modulation: 0%
  Burner # starts: 104927
  Total burner operating time: 364 days 11 hours 56 minutes
  Total heat operating time: 352 days 0 hours 23 minutes

Thermostat: Junkers FW200 (DeviceID:0x10 ProductID:106, Version:12.14)
  Clock: 10:40:13 17/08/2020
  Heating Circuit 1:
    Current room temperature: 23.7°C
    Setpoint room temperature: 15.0°C
    Mode: manual
    Mode Type: nofrost
  Heating Circuit 2:
    Current room temperature: 23.7°C
    Setpoint room temperature: 16.0°C
    Mode: manual
    Mode Type: nofrost

Mixing Module: Junkers IPM (DeviceID:0x21 ProductID:102, Version:20.08)
  Heating Circuit: 2
    Current flow temperature: 28.2°C
    Setpoint flow temperature: 0°C
    Current pump modulation: 0%
    Current valve status: 0

Mixing Module: Junkers IPM (DeviceID:0x20 ProductID:102, Version:20.08)
  Heating Circuit: 1
    Current pump modulation: 0%

Solar Module: Junkers ISM1 (DeviceID:0x30 ProductID:101, Version:23.04)
  Collector temperature (TS1): 38.2°C
  Bottom temperature (TS2): 62.5°C
  Solar Pump (PS1) active: off
  Pump working time: 202 days 9 hours 0 minutes
  Tank Heated: off
  Collector shutdown: off
  Energy last hour: 0.0Wh

And this is the output of the thermostat_data publish: {"hc1":{"seltemp":15,"currtemp":23.7,"mode":"manual","modetype":"nofrost"},"hc2":{"seltemp":16,"currtemp":23.7,"mode":"manual","modetype":"nofrost"}}

proddy commented 3 years ago

I removed the Rx queue on the latest v2_cmd. It never got more than one record in so no point using a buffer and expensive list. Makes the code tidier and I would expect slightly quicker. Apart from that no other side effects as far as I can tell.

I'm still getting the odd Rx corrupted telegrams. In my tests

conclusion? no idea. I think perhaps we've built a quantum computer where the observer is changing the outcome. I'm now running another test at 80Hz to see if that helps.

-- edit --

Aug 18 00:58:55 ems-esp - 000+04:57:02.114 E 11: [telegram] Rx: 17 0B A8 00 01 00 FF FF 8F (CRC 8F != 75)
Aug 18 01:21:55 ems-esp - 000+05:20:02.241 E 12: [telegram] Rx: 17 0B A8 00 01 00 FF F6 01 06 00 01 0D 01 00 FF FF 01 02 02 03 97 (CRC 97 != DD)
Aug 18 01:41:14 ems-esp - 000+05:39:21.362 E 13: [telegram] Rx: 17 08 1F 89 (CRC 89 != 53)
Aug 18 01:42:55 ems-esp - 000+05:41:02.366 E 14: [telegram] Rx: 17 0B A8 00 01 00 FF F6 01 06 00 01 0D 01 00 FF FF 01 02 02 02 00 00 05 1F 05 1F 02 0E 00 FF 89 (CRC 89 != DF)
Aug 18 02:50:55 ems-esp - 000+06:49:02.351 E 15: [telegram] Rx: 17 0B A8 00 01 00 FF F6 01 06 00 01 0D 01 00 FF FF 01 02 02 02 00 00 05 1F 05 1F 02 0E 00 FF 89 (CRC 89 != DF)
Aug 18 03:12:56 ems-esp - 000+07:11:02.754 E 16: [telegram] Rx: 17 0B A8 00 01 00 08 00 2A 00 00 00 00 00 00 00 00 01 06 00 00 80 00 00 80 00 80 00 80 00 00 B6 (CRC B6 != ED)
Aug 18 03:38:55 ems-esp - 000+07:37:02.253 E 17: [telegram] Rx: 17 0B A8 00 01 00 FF F6 01 06 00 01 0D 01 00 FF FF 01 02 02 02 00 00 05 1F 05 1F 02 0E 00 FF 89 (CRC 89 != DF)
Aug 18 03:54:37 ems-esp - 000+07:52:43.987 E 18: [telegram] Rx: FE 08 00 1C 00 00 2F 24 AC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 (CRC 38 != 05)
Aug 18 04:11:55 ems-esp - 000+08:10:02.375 E 19: [telegram] Rx: 17 0B A8 00 01 00 FF F6 01 07 89 (CRC 89 != EC)
Aug 18 05:23:55 ems-esp - 000+09:22:02.050 E 20: [telegram] Rx: 17 0B 91 00 80 CA 89 (CRC 89 != 5D)

they look like valid telegrams, just cut short because the BREAK is falsely detected.

FredericMa commented 3 years ago

I tried the latest code. It works like a charm! It shows the temps in the console and mqtt data. Thanks @MichaelDvP !

MichaelDvP commented 3 years ago

@proddy i've pushed a uart branch based on latest v2_cmd to make sure that the timer is not triggert by something else in the framework and sends a unwanted break.

proddy commented 3 years ago

@MichaelDvP just tried that now. Got the first Rx fail after 3 minutes (which is usual btw) so that change didn't seem to make a difference. I'll need to go back to a v2_cmd build where everything was working fine, and then do a diff.

MichaelDvP commented 3 years ago

My last rx errors were 15.8. as reported in #398, before there were also a few errors (not logged). I made a platformio update and platformio upgrade and i think that have fixed the errors, since there was no other change in the software. @FredericMa do you have rx/tx errors (i suppose tx_mode 3)?

FredericMa commented 3 years ago

@FredericMa do you have rx/tx errors (i suppose tx_mode 3)?

This is the status of ems:

EMS Bus is connected, but Tx is not stable.

EMS Bus info:
  Tx mode: 3
  Bus protocol: HT3
  #telegrams received: 8458
  #read requests sent: 9256
  #write requests sent: 7
  #incomplete telegrams: 0 (0%)
  #tx fails (after 3 retries): 1164

Tx Queue is empty

I guess I need to look at incomplete telegrams for failed reads? So those are 0 at 19h uptime. The failed tx are coming from Norberts hardware on RPi which is also still connected to the bus.

MichaelDvP commented 3 years ago

I guess I need to look at incomplete telegrams for failed reads? So those are 0 at 19h uptime.

Yes, that look good.

The failed tx are coming from Norberts hardware on RPi which is also still connected to the bus.

I remember, the rpi uses modem device-id, but do not reply to version request from ems-esp. So you get a tx-fail every minute.

proddy commented 3 years ago

I remember, the rpi uses modem device-id, but do not reply to version request from ems-esp. So you get a tx-fail every minute. we can make a simple change to ignore post-Tx checks when sending to one of the known ems-bus-ids (0xA, 0xB, 0xD, 0xF, 0x12)

still its nice to see that you have no incomplete Rx's.

FredericMa commented 3 years ago

Eventually I'll disconnect the RPi from the bus after I finish moving some remaining automations from OpenHAB to Home Assistant. So implementing a fix is not really necessary from my side.

proddy commented 3 years ago

My last rx errors were 15.8. as reported in #398, before there were also a few errors (not logged). I made a platformio update and platformio upgrade and i think that have fixed the errors, since there was no other change in the software.

I tested 8 different builds going back as early as b9 on the old v2 branch from July 28 and each test gave Rx incompletes every 1 hr or so. Then I tried rolling back the espressif core to 2.6.1 and 2.6.0 but that didn't help either. I can't figure out why we're seeing this now. I'll open a new Issue for this.

In any case it has nothing to do with the v2_cmd changes so I'll merge this back into v2.

proddy commented 3 years ago

merged into the v2 branch.