Closed proddy closed 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"}}
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.
I tried the latest code. It works like a charm! It shows the temps in the console and mqtt data. Thanks @MichaelDvP !
@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.
@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.
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 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.
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.
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.
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.
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.
merged into the v2 branch.
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:cmd
payload={"target":"boiler", "cmd":"flowtemp", "data":55}
cmd
payload={"target":"thermostat", "cmd":"mode", "data":"auto"}
cmd
payload={"target":"thermostat", "cmd":"mode", "id":2, "data":"auto"}
cmd
payload={"target":"system", "cmd":"fetch"}
cmd
payload={"target":"system", "cmd":"gpio", "id":1, "data":"on"}
2) The exception to the above is for Home Assistant's default climate component. Here the subscribed topic will behomeassistant/climate/ems-esp/hc<num>/<cmd_temp|cmd_mode>
. At some point, we should have our own component installed via HACS. 3) Console commands will be derived from the MQTT commands and accessible viaset <cmd> <data> [hc]
in the associated context. 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