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

[proddy]

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:

• topic=cmd payload={"target":"boiler", "cmd":"flowtemp", "data":55}
• topic=cmd payload={"target":"thermostat", "cmd":"mode", "data":"auto"}
• topic=cmd payload={"target":"thermostat", "cmd":"mode", "id":2, "data":"auto"}
• topic=cmd payload={"target":"system", "cmd":"fetch"}
• topic=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 be homeassistant/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 via set <cmd> <data> [hc] in the associated context. For example:

ems-esp:/$ boiler
ems-esp:/boiler$ set flowtemp 55
ems-esp:/boiler$ exit
ems-esp:/$ thermostat
ems-esp:/thermostat$ set temp 20 2
ems-esp:/thermostat$ set mode 2 auto

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

[proddy]

@MichaelDvP anything to add?

[MichaelDvP]

If all home automation systems can do that, it's ok.
Before you use "data", now "value", is there a special reason?
But i think normal json with : instead of = and how do you want to manage the different hc on thermostat?

{"target":"thermostat", "hc":2, "cmd":"mode", "value":"day"}

is than in telnet? As a context or a third parameter?

# thermostat
# hc 2
# mode day

The mqtt commands should have exactly the same name as the mqtt pubish. i.e. if published as mode the command should be mode not setmode.

How do you think about nested commands like {"thermostat":{"hc2":{"mode":"auto"}}} and
#thermostat hc2 mode auto

[proddy]

i was making changes while you were replying it seems - I think most of your comments have been addressed. I was thinking whether we should use 'mode' or 'setmode'. The reason I choose 'set' was 1) because it's an action and 2) maybe one day we'll need to add a get command to query a value via MQTT. But thinking about it more you're right. How about the command is 'mode' and in the console the command would be set mode <hc> <data>

[proddy]

worked a bit of this today. It changes a lot of files so needs careful testing.

[MichaelDvP]

I have thought about that an tested in small range only inside thermostat and would prefer if the command is
set <cmd> <data> [hc]
with hc optional as last parameter defaults to first active hc if not set. Also there is no confusion with thermostat global- and boiler-commands: set <cmd> <data>

(this was my test-command finally: thermostat_set_command.txt)

[proddy]

that's good since my implementation follows that same standard. I fixed a few bugs along the way too. Now you just need to register the command and it'll will propagate to the mqtt and console functions. Since it's quite a major change I'll create a feature branch and let you know when it's pushed.

[proddy]

@MichaelDvP I'm working on the thermostat bit now. I see you implemented parsing of nested commands like
{"hc2":{"temp":21}}.

Is this important to have? It adds a lot of complexity to the new code I'm refactoring. Wouldn't just
{"cmd":"temp", "hc":"1", data="21"} suffice? Or do you have a specific use case.

[MichaelDvP]

No, not important. I added this a while ago in 1.5 for me and when switching to 2.0 some of my scripts were using it, but easy to change.
For the actual splitting in boiler_cmd/boiler_data and thermostat_cmd/thermostat_data i also find it more intuitive to use the same structure for data and command. But if you go for a single cmd it's clear to use a different structure.
(I think you plan to deserialize in the cmd-function to check the target and the thermostat-on-command will receive cmd, data, hc seperated)
BTW: i forgot some thermostat commands to add to cmd/data.

[proddy]

Right now I took a slightly different approach. I eliminated the 'target'. Now each device when its recognized will subscribe to its own MQTT topic called "<device>_cmd" like thermostat_cmd and boiler_cmd. There is a special one for the system.

The payload must have a cmd and optional are data, id, or hc. So these are all valid

thermostat_cmd {"cmd":"temp", "hc":1, "data"="21"} // hc must be numeric
thermostat_cmd {"cmd":"temp", "data"="21"} // hc is optional
thermostat_cmd {"cmd":"temp", "data"="21", "id":1} // id here is the same as hc
boiler_cmd {"cmd":"comfort", "data"="eco"}
system_cmd {"cmd":"gpio", "id":1, "data"="on"} // sets D1 to HIGH

this does impose some restrictions imposed by the json library that I'm not happy about, like

• the data must be always be a string, so represented in quotes e.g. "data":"blah"
• the id and hc must always be a numeric value, e.g. "id":1
• it assumes there is only one data element and an optional id. It most cases this is fine but there may be situations where more variables are needed, like 'set temp holiday 22?

will this work?

[proddy]

also @MichaelDvP I'm not to happy using the set command as it conflicts with the internal settings of EMS-ESP.
e.g. set master <n> or set tx_mode <n> change the settings which are also available via the web.

where set comfort eco in the boiler context is used to request a change on an EMS device. I think a better word would be call or cmd or change.

?

[MichaelDvP]

cmd looks a bit odd in the help as cmd <cmd> <data>, change <cmd> <data> is much better, or use ems <cmd> <data> since it changes a ems value.

on the other hand, cmd is more in line with the mqtt command.

[proddy]

It really needs to be a verb, like set is. So options are
run <cmd>
exec <cmd>
call <cmd>
do <cmd>

I'll stick with call for now. It's only one line that needs to be changed anyway ;-)

[proddy]

I created a branch https://github.com/proddy/EMS-ESP/tree/v2_cmd with the latest changes. There's quite a bit. Still needs some more testing but let me know if you run into issues.

This branch has all the latest updates from v2.

I've been using the standalone build for testing. If you have gcc installed type make run and it'll run the simulation with a few tests being automatically executed.

[MichaelDvP]

I made a real word test first, but limited to my system.
some fixes:

• helpers:value2xxx should be called by reference i.e. value2float(const char * v, float & value)
• thermostat::set_temperature_value should have hc as int8_t
• use AUTO_HEATING_CIRCUIT instead of DEFAULT
• mixing gpio and Wemos-D-numbers leads to confusion.

some observations:

• free memory seems to be much lower now (~22% with telnet open, ~42% with telet closed)
• only subscriptions for thermostat and boilder, system_cmd is missing
• mqtt reconnects every 5 minutes (exactly 297 seconds)
• direct after the reconnect i get these messages from [mqtt]:

000+00:33:48.578 I 34: [mqtt] MQTT disconnected: TCP
000+00:33:53.593 I 35: [mqtt] MQTT connected
000+00:33:54.200 E 36: [mqtt] No MQTT handler found for topic thermostat_cmd and payload {"cmd":"summertemp","data":"14"}
000+00:33:55.903 I 37: [thermostat] Setting thermostat temperature to 14.0 for heating circuit 2, mode summer
000+00:33:55.903 E 38: [mqtt] No MQTT handler found for topic thermostat_cmd and payload {"cmd":"summertemp","data":"14"}
000+00:38:50.559 I 39: [mqtt] MQTT disconnected: TCP
000+00:38:55.575 I 40: [mqtt] MQTT connected

[proddy]

thanks for testing and the feedback.

[proddy]

only subscriptions for thermostat and boiler, system_cmd is missing

I called it system, Should it be system_cmd ?

[proddy]

mixing gpio and Wemos-D-numbers leads to confusion.

What do you suggest? Stick to the GPIO numbers or D numbers? It uses D* numbers now and maps to gpio values (using your code). Should the command be renamed to "pin" for example?

[proddy]

mqtt reconnects every 5 minutes (exactly 297 seconds)

I'm not seeing this. Been running for 15hrs will no MQTT errors. Make sure you don't have multiple EMS-ESPs running (e.g. ESP8266 and ESP32) using the same MQTT client ID.

I'll keep testing

[MichaelDvP]

The esp32 has a lot of spare gpio, most without wemos D-numbers, so it's better to use gpio, but readme/wiki should note the difference to D-numbers.

The reconnects are gone when i clear the value in my mqtt broker. Also there no more error messages. I guess the commands are registered after subscription of thermostat_cmd, but the broker connection is publish on subscribe. I'll try with QoS.

I don't have a system subscription, but i see this.
// add the system MQTT subscriptions, only if its a fresh start with no previous subscriptions

[proddy]

there was a bug in the MQTT re-subscribe so I fixed that. Also renamed the topic to "system_cmd" so it's consistent with the rest.

I'll change to use the gpio numbers. This also means your MQTT logic will change too as I believe the code you added took pin numbers D0-D3. Ok if I change that?

[MichaelDvP]

The D0-D3 was from #375. Since the command has changed, there is no problem. I think it's clear that `gpio' command also means gpio-numbers.

[proddy]

changed it anyway :-) pin <gpio> [data]. In MQTT the id is the gpio,

[MichaelDvP]

@FredericMa

This command if failing on topic ems-esp/thermostat_cmd :
{"cmd":"nofrosttemp" ,"data":17, "id":1}

"data":17does not work anymore, you have to use "data":"17" (with quotation marks)

@proddy i don't think this is realy needed. For manual testing it's less typing, but for normal operation it's no problem to send two or more commands in a row.

[proddy]

"data":17does not work anymore, you have to use "data":"17" (with quotation marks)

yes, this sucks so I'm working on change that allows the data and id to be a string or a number.

[MichaelDvP]

Q&D this works:

                if (doc["data"] == nullptr) {
                    LOG_ERROR(F("MQTT error: invalid payload cmd format. message=%s"), message);
                    return;
                }
                const char * data = doc["data"];
                char data1[30];
                if (data == nullptr) {
                    if (float f = doc["data"]) {
                         Helpers::render_value(data1, f, 10);
                    }
                } else {
                    strcpy(data1, data);
                }

if (!call_command(mf.device_type_, command, data1, n)) {

[proddy]

that would work too. I used JsonVariant id = doc["id"]; if (id.is<char*>()) { etc...

[FredericMa]

Do you have a use case you can share so I understand how you're building these MQTT payloads? Is this something that Domoticz does for example?

Actually I use it for the heat mode. I'm using Home Assistant but implemented some custom code since circuit is controlling the radiators circuit (on the second floor) but on that circuit I have valves that are controlled via KNX. So the KNX valve controller has a bit that indicates heat demand. This is captured by HA and that enables the heating circuit via ems-esp. I want the circuit 1 water temp to be around 65°C so I set the circuit 1 setpoint to current room temp + 5°C. The thermostat actually uses the current room temperature of circuit 2 (floor heating on ground floor) for circuit 1. By using current room temp + 5°C the heater will always target approx 65°C. The it is up to the valves to control the target temperature in each room.

Like Michael says, it is not necessary to have the ability to chain multiple commands. Two separate commands works fine as well.

[FredericMa]

Something else I noticed:
I can still set the mode to "heat". I guess because of the mapping over here: https://github.com/proddy/EMS-ESP/blob/67877d07c51b5e456e86bc55ec334151e3c827b1/src/devices/thermostat.cpp#L1497-L1512
But I'm unable to use the heattemp command because only nofrosttemp, nighttemp and daytemp are registered.

Also the reported mode_type is heat, eco or nofrost according to this code I guess:
https://github.com/proddy/EMS-ESP/blob/67877d07c51b5e456e86bc55ec334151e3c827b1/src/devices/thermostat.cpp#L627-L636

So if you set nofrosttemp this is for nofrost mode_type that is also reported as mode_type nofrost which is OK.
But the following can cause some confusion since if you set nighttemp and night mode_type, you actually set the temp and mode_type for the mode_type that will be reported as eco.
The same for daytemp and mode_type day which modify the mode_type reported as heat.

So maybe this needs some alignment?

[proddy]

First we need to get the right commands for your Junkers thermostat. Could you look at the code in Thermostat::add_commands() and let me know which commands should be supported?

Then for the mapping of modes, are you saying when you change the temperature for a mode (like daytemp or nighttemp) it should also automatically switch the mode? Or is it that the reported mode is just in correct?

[FredericMa]

First we need to get the right commands for your Junkers thermostat. Could you look at the code in Thermostat::add_commands() and let me know which commands should be supported?

According to the thermostat the supported modes are Automatic, Comfort, Economy, and Frost
So that would map to auto, comfort (or heat), eco and nofrost.

There also seems to be a Vacation mode in the thermostat but I never used that before. The description for that mode is:
You can use this function if you want to set a constant operating mode for several days (e.g. Frost ) without changing the heating program. When the vacation program is active, the heating circuits and domestic hot water systems are operated according to the operating mode set in the vacation program (frost protection is automatically provided).

Then for the mapping of modes, are you saying when you change the temperature for a mode (like daytemp or nighttemp) it should also automatically switch the mode? Or is it that the reported mode is just in correct?

Indeed, I wanted to point out that reported mode is incorrect, or I would rather say inconsistent compared to the sent command.

[MichaelDvP]

If i understand correctly the actual situation is:

• Your thermostat is a Junkers FW?
• The thermostat shows modes: Automatic | Comfort | Economy | Frost
• Ems-esp shows on telnet:
  mode: Manual | Auto | Holiday
  modetype: heat | eco | nofrost
• mqtt publish for mode and modetype is the same as terminal
• mqtt commands for mode is heat | eco | nofrost | auto, also working day | night | nofrost | auto
• Ems-esp shows on terminal and mqtt only daytemp, nighttemp Edit: actually not shown, telegram SetJunkers is not read
• Ems-esp commands on mqtt and call are daytemp, nighttemp, nofrosttemp

You like to have the temperature publish and commands to be heattemp, ecotemp, nofrosttempand add the missing nofrosttemp to the publish, right?

[FredericMa]

Your thermostat is a Junkers FW?

Yes, FW200 to be pricise, so I cannot confirm that this report is valid for other Junkers thermostats.

The thermostat shows modes: Automatic | Comfort | Economy | Frost
Ems-esp shows on telnet:
mode: Manual | Auto | Holiday
modetype: heat | eco | nofrost

Yes, that is correct.

mqtt publish for mode and modetype is the same as terminal

Also correct

mqtt commands for mode is heat | eco | nofrost | auto, also working day | night | nofrost | auto

Yes

Ems-esp shows on terminal and mqtt only daytemp, nighttemp Edit: actually not shown, telegram SetJunkers is not read

Maybe I don't understand the question correctly but the setpoints are shown correctly for all modes. The shown mqtt subscriptions for thermostat are these:
topic: ems-esp/thermostat_cmd, [cmd]: wwmode temp mode nofrosttemp nighttemp daytemp

Ems-esp commands on mqtt and call are daytemp, nighttemp, nofrosttemp
Yes
You like to have the temperature publish and commands to be heattemp, ecotemp, nofrosttemp and add the missing nofrosttemp to the publish, right?

nofrosttemp is actually working since @proddy added the command. It is heattemp and ecotemp that are not working but daytempand ´nighttemp` do work. See line from terminal above.

[MichaelDvP]

Maybe I don't understand the question correctly but the setpoints are shown correctly for all modes. The shown mqtt subscriptions for thermostat are these:
topic: ems-esp/thermostat_cmd, [cmd]: wwmode temp mode nofrosttemp nighttemp daytemp

I mean the publish, not the subscription.

• if you type show in terminal you get a lis of values, but i think the setpoints are missing for Junkers.
• in mqtt publish thermostat_data the setpoints are also missing

[FredericMa]

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]

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

• with tx_mode 1 after 12hrs I got 39 Rx failures
• with tx_mode 0 and the Tx line completely disconnected (so no Tx), after 7hrs I got 3 Rx failures

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 --

• running at 80Hz made no difference
• back on tx_mode 1, after 9hrs 16 Rx failures again
• rolled back to earlier UART, made no difference
• conclusion: it's not the UART or roomcontrol changes, but something else in the cmd infrastructure changes from this issue. Now I have to reverse engineer bit by bit to find out why.

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]

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

[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.

[proddy]

@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]

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]

@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]

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]

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]

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]

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]

merged into the v2 branch.