1.20j, ME81AH issue

[EugenePanyaev]

1. When we send the target temperature through mqtt message to thermostat1/thermostat/set/targetTemperature value at thermostat1/thermostat/properties/targetTemperature not updated. At firmware 1.19 it works

2. When we change the temperature on the device with the buttons, the value thermostat1/thermostat/properties/targetTemperature is also not updated

Same with deviceOn and locked properties - after setting via mqtt updated on device, not updated in mqtt

3. When option "Send all MCU commands via MQTT" disabled, but unknown mcu messages arrives

[klausahrenberg]

Thanks for feedback. I can say, the BHT-002 runs smoothly. But I also have another device ME102H, that has some similarities to your device - and this one doesn't run well yet. For some reason, the MCU sends messages after interactions on the device and sometimes not - this is related to your topic 2. I will improve this on next update. Your topic 1 I can not confirm. Are you sure that you didn't try to modify the target temperature, when schedules mode is 'auto'? Because then it's not possible to change the value.

I will check and keep you updated

[EugenePanyaev]

I checked. The schedule mode is manual. I looked here :-), I have a ME81H model. But it seems to me there is no difference?

[klausahrenberg]

Unknown MCU message should not arrive anymore Please check scheduleMode issue with v1.20l

[EugenePanyaev]

Its OK now. Thank you very much! Can already be used in real work! When changing values on the device, they are updated in mqtt - everything works.

But there is instability. The video shows everything. When we send a new temperature value or a new deviceOn state, the property value is updated in mqtt, but it does not change on the device. After 1-2 seconds, the value of the mqtt property reverts to the value on the device. This situation is clearly visible on the Thermostat_state element.

[klausahrenberg]

OK, the it seems that the command for target temp of deviceOn was not accepted by the device. I only implemented an additional query of device state every 2 seconds because sometimes the feedback of device after changes is missing. In your case the device didn't accepted the change and after requery a 2 seconds later the origin value from the device is actual again.

I have to check, next round...

[Gulpman]

Just as an additional confirmation that V1.20l fixed the "Unknown MCU command" message on the ME81H: I had the same issue (error message) with V1.20k. Updated to 1.20l and the error message no longer appers in the mqtt message.

So far I only tested by pressing the up down arrows on the device as I'm slowly trying to get into the matter.

[GUVWAF]

I can confirm the instability issues @EugenePanyaev is experiencing with the ME81H. The same problem seems to happen with the set/targetTemperature MQTT command. If there is any information you want to have about this device, please let us know.

[klausahrenberg]

When we send a new temperature value or a new deviceOn state, the property value is updated in mqtt, but it does not change on the device. After 1-2 seconds, the value of the mqtt property reverts to the value on the device.

Please check now with v1.20m. schedulesMode setting should work now - about targetTemperature I am unsure on your devices, please test.

[EugenePanyaev]

When we send a new temperature value or a new deviceOn state, the property value is updated in mqtt, but it does not change on the device. After 1-2 seconds, the value of the mqtt property reverts to the value on the device.

Please check now with v1.20m. schedulesMode setting should work now - about targetTemperature I am unsure on your devices, please test.

Same result - instability

[GUVWAF]

Indeed, setting 'deviceOn' is still instable on the ME81H. The value of 'temperature' and 'state' does seem to change accordingly. However, now I cannot change 'targetTemperature' via MQTT at all (whereas I could sporadically using v1.20l). Reading its value via MQTT always gives 22.00 even if I change it on the device. After around 3 minutes, the value of the device also changes back to 22 degrees.

[J-rethinkmx]

The ME81H has poor inbound RX command handling. If 2 MCU commands are sent with little time in-between then it looses one or both of them. With a MCU handshaking required every 10 seconds that command will happen during the "loop" processing. Commands coming in from the HTTP or MQTT processing can stack right behind that handshaking MCU command and hence.... 2 MCU commands back to back.

I put some queuing logic into the 1.18 version and it worked nicely. Now with 1.20 I need to put that logic back in..... while doing all the other things i need to do outside of this project... yikes!

[klausahrenberg]

I put some queuing logic into the 1.18 version and it worked nicely. Now with 1.20 I need to put that logic back in.

Could you send me your implemenattion of 1.18?

[J-rethinkmx]

I can seem to have permissions to upload anything to the repository. What's the best way to get a file up to you?

[klausahrenberg]

What's the best way to get a file up to you?

Hi, zip your file and attach this to a reply in this thread

[J-rethinkmx]

Couldn’t seem to figure out how to link attachments…. Doh!

The queuing system is a “shiftable” array holds the current serial command being executed and any commands that follow when a response is waiting from the current serial command. There are 5 touch points • Constructor – initialization • commandCharsToSerial – queues the command based on type, state, parms, etc. This was not added to the Hex version • Loop – The mechanism and other startup handshake commands are handed through a processing state. The handling of this is in loop. Timeouts are handled by reissuing the top q element. Only once is supported. When the state changes to command idle (after a response is received) the current element is popped and the next command if any is executed • processSerialCommand – based on the command type, the processing state changes. I didn’t check for a response that matches the dpid of the comment. Would be ideal, however things were working okay without it • Various “To MCU” methods. Currently only targetTemperatureManualModeToMcu and schedulesModeToMcu. The other methods just need to add another parm to the commandCharsToSerial call

If you have any questions then just holler…. John

WBecaDevice.zip

[tsrubar]

I have exactly same instability issue with targetTemperature on ME81H running 1.20m. For a few moments I got impression, that setting qos higher helped, but after a while it started to behave same as before. Maybe coincidence. Really looking forward to patch as I am choosing right thermostat model to buy 10 more for zone heating in our house, so this one fit well with its price tag. Or maybe someone could point me to model that is in similar price level and dont suffer from such issues.

[klausahrenberg]

@J-rethinkmx : Hi John. After long time today I implemented your MCU communication handling in v1.20n. At my device ME102H this solved the sluggish behavior and inconsitense status updates at device changes. However, not fully tested yet. Please test the behavior witch ME81AH - I hope, it's better now. At the moment I disabled your message queuing, because I see no difference in MCU communication with my device - no commands are getting lost that bufferiung is necessary. If this is not working with ME81AH, give me a message - the queuing can be enabled at every time - I would add this in the Web interface as an option.

https://github.com/klausahrenberg/WThermostatBeca/releases

Keep in mind that this is a beta release. Please test and give feedback, if problems occur.

[tsrubar]

Hi, thanks a lot, handling set targetTemperature is MUCH better now on ME81AH. Great job!

[neergaby95]

Its OK now. Thank you very much! Can already be used in real work! When changing values on the device, they are updated in mqtt - everything works.

But there is instability. The video shows everything. When we send a new temperature value or a new deviceOn state, the property value is updated in mqtt, but it does not change on the device. After 1-2 seconds, the value of the mqtt property reverts to the value on the device. This situation is clearly visible on the Thermostat_state element.

hello, can you give me the code configuration yaml for the thermostat, please? i don't known how to make to set temp via HA thermostat interface to mcu

[honzapatCZ]

Apparently Esphome solved the springback issue by just spamming the mcu until it responds.