search

absalom-muc / MHI-AC-Ctrl

Reads and writes data (e.g. power, mode, fan status etc.) from/to a Mitsubishi Heavy Industries (MHI) air conditioner (AC) via SPI controlled by MQTT
MIT License
270 stars 61 forks source link

Troom spikes when using MQTT as temperature source #105

Closed tomm1ed closed 1 year ago

tomm1ed commented 1 year ago

I am using an external Temperature sensor to set the Troom value on my SRC35ZSX but I see weird spikes when heating in the value, it kinda looks like the internal sensor also keeps updating (near the Airco of course it is hotter than at the temp sensor which is on the other end of the room)

See https://tweakers.net/fotoalbum/image/ax3hBggwaNhKPqMj9ZOg04s7.jpg for the temperature the Airco is reporting in the MQTT topic and https://tweakers.net/fotoalbum/image/CPcGYRJTto0jOrhyxENbRJuf.jpg for the actual temperature measurement. The value of Troom is updated every minute from the ESP (running Tasmota) through MQTT

Blokkert commented 1 year ago

Same issue here.

see: https://tweakers.net/fotoalbum/image/W3rlt7D76CKyctGQlkOCe448.png both values in one graph.

its worst on the moment the unit is in heating mode, spikes continously. When unit is off, sometimes a spike is happening. Tried different things in the mqtt.publish, but problems stays everytime.

Current code:

 # Airco

- id: Tuya Room Temp To AC-Living
  alias: Tuya Room Temp To AC-Living
  trigger:
  - platform: time_pattern
    minutes: /1
#  - platform: state
#    entity_id:
#      - sensor.temptuya1_temperature
  condition:
  - condition: template
    value_template: "{{ states('sensor.temptuya1_temperature')|is_number }}"
  action:
  - service: mqtt.publish
    data:
      topic: AC_MHI_Living/Troom
      payload_template: "{{ states('sensor.temptuya1_temperature') }}"
  mode: single

tried this to, no difference.

payload_template: '{{ states.sensor.temptuya1_temperature.state }}'

tomm1ed commented 1 year ago

My setup uses Tasmota with the following rules:

rule1 ON BMP280#Temperature DO Var1 %value% ENDON
rule2 ON Time#Minute|1 DO publish MHI-AC-Ctrl-Livingroom/Troom %Var1% endon
rule1 1
rule2 1
tomm1ed commented 1 year ago

Created a graph with both values superimposed (never knew this was possible, thanks @Blokkert ;) )

And a zoomed version during heating:

absalom-muc commented 1 year ago

Can you provide a log file? Maybe something happens in between.

tomm1ed commented 1 year ago

Can you provide a log file? Maybe something happens in between.

A log file of what exactly? Happy to provide anything you need to troubleshoot

absalom-muc commented 1 year ago

The log of the serial interface to see what happens between 2 spikes.

tomm1ed commented 1 year ago

The log of the serial interface to see what happens between 2 spikes.

Okay, excuse me for being a bit daft but how can I access this log?

Blokkert commented 1 year ago

i did check something reqarding mqtt timeout, its configured on 20 sec. So i changed the mqtt.publish to every 10 seconds, issue stays te same.

absalom-muc commented 1 year ago

The log of the serial interface to see what happens between 2 spikes.

Okay, excuse me for being a bit daft but how can I access this log?

If you used the Arduino IDE for programming the MHI-AC-Ctrl board, you can use the serial monitor of the Arduino IDE for displaying the log output. Please copy the log to a text file.

absalom-muc commented 1 year ago

i did check something reqarding mqtt timeout, its configured on 20 sec. So i changed the mqtt.publish to every 10 seconds, issue stays te same.

When you mention the mqtt.publish, I assume you mean the publish from your external temperature sensor - correct?

PietNL commented 1 year ago

As I'm also using this feature (also with HA) and not seeing these spikes, I just compared my automation with yours and noticed that you are using this:

  - service: mqtt.publish
    data:
      topic: AC_MHI_Living/Troom
      payload_template: "{{ states('sensor.temptuya1_temperature') }}"

And I'm posting the temp sensor to a different topic(including the set):

action:
  - service: mqtt.publish
    data:
      topic: AC-Living/set/Troom
      payload_template: "{{ states('sensor.living_temperature') }}"

If you try this, does that make a difference?

tomm1ed commented 1 year ago

As I'm also using this feature (also with HA) and not seeing these spikes, I just compared my automation with yours and noticed that you are using this:

  - service: mqtt.publish
    data:
      topic: AC_MHI_Living/Troom
      payload_template: "{{ states('sensor.temptuya1_temperature') }}"

And I'm posting the temp sensor to a different topic(including the set):

action:
  - service: mqtt.publish
    data:
      topic: AC-Living/set/Troom
      payload_template: "{{ states('sensor.living_temperature') }}"

If you try this, does that make a difference?

Do you mean you don’t see these spikes on your install?

tomm1ed commented 1 year ago

The log of the serial interface to see what happens between 2 spikes.

Okay, excuse me for being a bit daft but how can I access this log?

If you used the Arduino IDE for programming the MHI-AC-Ctrl board, you can use the serial monitor of the Arduino IDE for displaying the log output. Please copy the log to a text file.

Ah thank you, now I feel double daft. As my airco is quite high reaching the USB port is very hard, so I am hoping someone else can supply this info. (Or is there any way to get this info over the network?)

tomm1ed commented 1 year ago

As I'm also using this feature (also with HA) and not seeing these spikes, I just compared my automation with yours and noticed that you are using this:

  - service: mqtt.publish
    data:
      topic: AC_MHI_Living/Troom
      payload_template: "{{ states('sensor.temptuya1_temperature') }}"

And I'm posting the temp sensor to a different topic(including the set):

action:
  - service: mqtt.publish
    data:
      topic: AC-Living/set/Troom
      payload_template: "{{ states('sensor.living_temperature') }}"

If you try this, does that make a difference?

Do you mean you don’t see these spikes on your install?

The difference is just a naming of the entities in your installation and configuration. That has nothong to do with the spikes.

Thank you for you reply! My question is in my view quite a relevant question. Does the Troom follow your ‘set/Troom’ command and does it also result in no spikes?

Also; where did you get this info? I am running the version before the most current one and this topic was not mentioned anywhere as far as I remember. I am also unable to find the ‘set/Troom’ in the current documentation nor MHI-AC-CTRL.h so I am wondering how you knew to use that topic.

absalom-muc commented 1 year ago

Great finding @PietNL , thank you!

For MQTT publish to MHI-AC-Ctrl you have to use the set-path, please compare with SW-Configuration.md Publishing to AC_MHI_Living/Troom has no effect (not considered by MHI-AC-Ctrl) and will be overwritten by MHI-AC-Ctrl.

Blokkert commented 1 year ago

Great finding @PietNL , thank you!

For MQTT publish to MHI-AC-Ctrl you have to use the set-path, please compare with SW-Configuration.md Publishing to AC_MHI_Living/Troom has no effect (not considered by MHI-AC-Ctrl) and will be overwritten by MHI-AC-Ctrl.

Hmm, i already tried the /set/ topic earlier without any results, the troom value goes directy to internal temp sensor. So does'nt work at all here..

Will check the config.md later, since i bought a device with this software ready to run :)

tomm1ed commented 1 year ago

@absalom-muc on my MQTT broker this is what I see when using /set/Troom topic (using the command )

mosquitto_sub -h [MQTT-IP] -v -t "MHI-AC-Ctrl-Livingroom/#"

:

MHI-AC-Ctrl-Livingroom/set/Troom 18.6
MHI-AC-Ctrl-Livingroom/cmd_received unknown command

I am using Version 2.5R21 according to topic MHI-AC-Ctrl-Livingroom/AC-Livingroom

Blokkert commented 1 year ago

my version is set on 2.5R21 also, i can upgrade this to 2.6R2 and will report back when completed. Doing this somewhere this week.

tomm1ed commented 1 year ago

Okay, just checked my sourcecode triggered by the releasenotes of the newer versions:

removed switch ROOM_TEMP_MQTT in support.h, a Troom MQTT set command is always considered

and lo and behold...

//#define ROOM_TEMP_MQTT                            // use room temperature from received MQTT topic

in stead of

#define ROOM_TEMP_MQTT                            // use room temperature from received MQTT topic

[Edit] @absalom-muc should ArduinoOTA still work? I am getting zero response from the device:

espota.py -i 192.168.1.170 -d -P 18266 -f C:\Users\user\AppData\Local\Temp\arduino_build_719660\MHI-AC-Ctrl.ino.bin
11:43:13 [DEBUG]: Options: {'esp_ip': '192.168.1.170', 'host_ip': '0.0.0.0', 'esp_port': 8266, 'host_port': 18266, 'auth': '', 'image': 'C:\\Users\\user\\AppData\\Local\\Temp\\arduino_build_719660\\MHI-AC-Ctrl.ino.bin', 'spiffs': False, 'debug': True, 'progress': False}
11:43:13 [INFO]: Starting on 0.0.0.0:18266
11:43:13 [INFO]: Upload size: 334464
11:43:13 [INFO]: Sending invitation to: 192.168.1.170
11:43:13 [INFO]: Waiting for device...
11:43:23 [ERROR]: No response from device

[Update2] Never mind, frigging Windows Firewall was blocking silently....

And fixed:

MHI-AC-Ctrl-Livingroom/set/Troom 18.8
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/Troom 18.75
tomm1ed commented 1 year ago

It appears I spoke too soon :( It's gotten even worse:

In MQTT I see:

MHI-AC-Ctrl-Livingroom/set/Troom 19.2
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/Troom 19.0
MHI-AC-Ctrl-Livingroom/Troom 23.00
MHI-AC-Ctrl-Livingroom/set/Troom 19.2
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/Troom 19.00

@absalom-muc any insight? The airco is not running and it's nowhere near 23 degrees in my livingroom.

Erratum: It looks like somehow the 'Return-AIR Operating Data' is involved? After the updated firmware was loaded on my AC it show the same graph:

Blokkert commented 1 year ago

Seems that the problems are solved here.

  1. I upgraded to 2.6R2
  2. mqtt timeout is set on 60 seconds
  3. added /set/ in the payload
  4. my mqtt.publish from HA is running every 45 seconds

Spikes are gone.

I noticed, the troom has a accuracy of 0.5 degrees. Sending value of 19,67 results of troom of 19,5 19,81 results in 19,5 etc.

But thats all fine.

You can see the moment i fixed everything according above listed points:

photo1666859137

tomm1ed commented 1 year ago

Seems that the problems are solved here.

1. I upgraded to 2.6R2

2. mqtt timeout is set on 60 seconds

3. added /set/ in the payload

4. my mqtt.publish from HA is running every 45 seconds

Spikes are gone.

I noticed, the troom has a accuracy of 0.5 degrees. Sending value of 19,67 results of troom of 19,5 19,81 results in 19,5 etc.

But thats all fine.

You can see the moment i fixed everything according above listed points:

photo1666859137

Looks like I need to migrate to 2.6R2 then... I will do this tomorrow.

tomm1ed commented 1 year ago

Updated to 2.6R2 and it looks like it's better, but not fixed. The spike to 23 returns now and then:

MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/Troom 19.50
MHI-AC-Ctrl-Livingroom/OpData/THI-R3 17
MHI-AC-Ctrl-Livingroom/OpData/CT 0.00
MHI-AC-Ctrl-Livingroom/OpData/OU-FANSPEED 0
MHI-AC-Ctrl-Livingroom/OpData/DEFROST Off
MHI-AC-Ctrl-Livingroom/OpData/TOTAL-COMP-RUN 200
MHI-AC-Ctrl-Livingroom/OpData/OU-EEV1 250
MHI-AC-Ctrl-Livingroom/OpData/RETURN-AIR 19.50
MHI-AC-Ctrl-Livingroom/OpData/TDSH 0
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/OpData/TDSH 0
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/OpData/THI-R2 64
MHI-AC-Ctrl-Livingroom/OpData/OUTDOOR 12.00
MHI-AC-Ctrl-Livingroom/OpData/THO-R1 3
MHI-AC-Ctrl-Livingroom/OpData/THO-R1 2
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/OpData/THO-R1 3
MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/OpData/THO-R1 2

MHI-AC-Ctrl-Livingroom/Troom 23.00

MHI-AC-Ctrl-Livingroom/set/Troom 19.5
MHI-AC-Ctrl-Livingroom/cmd_received o.k.
MHI-AC-Ctrl-Livingroom/Troom 19.50
[...]

Also visible in the Graphs in Home Assistant: My other ZSX with external DS18x20 does not have this issue. (running 2.5R21)

@absalom-muc any insight would be much appreciated

[Update] The spike now occurs every 34 minutes exactly: 8:28:00 9:12:00 9:56:00

and within 1-2 seconds is reset to the actual temp provided via MQTT.

Running command 

mosquitto_sub -h 192.168.1.23 -v -t "MHI-AC-Ctrl-Livingroom/#" |  ts | grep 'Troom\|cmd_received'

shows the following when the wrong temp is posted:

Oct 28 10:59:00 MHI-AC-Ctrl-Livingroom/set/Troom 19.6
Oct 28 10:59:00 MHI-AC-Ctrl-Livingroom/cmd_received o.k.
Oct 28 10:59:00 MHI-AC-Ctrl-Livingroom/Troom 23.25
Oct 28 10:59:00 MHI-AC-Ctrl-Livingroom/Troom 19.50
[...]
Oct 28 11:14:00 MHI-AC-Ctrl-Livingroom/set/Troom 19.6
Oct 28 11:14:00 MHI-AC-Ctrl-Livingroom/cmd_received o.k.
Oct 28 11:14:00 MHI-AC-Ctrl-Livingroom/Troom 23.25
Oct 28 11:14:00 MHI-AC-Ctrl-Livingroom/Troom 19.50

so within one second the temp spikes to 23.25 and immediately goes to the correct value.

Could it somehow have something to do with this piece of code?

  // fallback to AC internal Troom temperature sensor
  if(troom_was_set_by_MQTT & (millis() - room_temp_set_timeout_Millis >= ROOM_TEMP_MQTT_SET_TIMEOUT*1000)) {
    mhi_ac_ctrl_core.set_troom(0xff);  // use IU temperature sensor
    Serial.println(F("ROOM_TEMP_MQTT_SET_TIMEOUT exceeded, use IU temperature sensor value!"));
    troom_was_set_by_MQTT=false;
  }

Added a MQTT publish in that function which did not fire so that's not the issue. However when the issue arrises this is what I see:

Oct 28 12:08:02 MHI-AC-Ctrl-Livingroom/set/Troom 19.8
Oct 28 12:08:20 MHI-AC-Ctrl-Livingroom/Troom 19.75
Oct 28 12:08:20 MHI-AC-Ctrl-Livingroom/Errorcode 0
Oct 28 12:08:20 MHI-AC-Ctrl-Livingroom/Troom 23.25
Oct 28 12:08:21 MHI-AC-Ctrl-Livingroom/OpData/Mode Heat
Oct 28 12:08:23 MHI-AC-Ctrl-Livingroom/OpData/Tsetpoint 19.0
Oct 28 12:08:25 MHI-AC-Ctrl-Livingroom/OpData/TOTAL-COMP-RUN 200
Oct 28 12:08:27 MHI-AC-Ctrl-Livingroom/OpData/RETURN-AIR 23.25
Oct 28 12:08:29 MHI-AC-Ctrl-Livingroom/OpData/THI-R1 18
Oct 28 12:08:31 MHI-AC-Ctrl-Livingroom/OpData/THI-R2 71
Oct 28 12:08:33 MHI-AC-Ctrl-Livingroom/OpData/IU-FANSPEED 0
Oct 28 12:08:35 MHI-AC-Ctrl-Livingroom/OpData/TOTAL-IU-RUN 300
Oct 28 12:08:37 MHI-AC-Ctrl-Livingroom/OpData/OUTDOOR 22.25
Oct 28 12:08:39 MHI-AC-Ctrl-Livingroom/OpData/THO-R1 9
Oct 28 12:08:41 MHI-AC-Ctrl-Livingroom/OpData/COMP 0.00
Oct 28 12:08:43 MHI-AC-Ctrl-Livingroom/OpData/TD <=30
Oct 28 12:08:45 MHI-AC-Ctrl-Livingroom/OpData/THI-R3 18
Oct 28 12:08:47 MHI-AC-Ctrl-Livingroom/OpData/CT 0.00
Oct 28 12:08:49 MHI-AC-Ctrl-Livingroom/OpData/TDSH 0
Oct 28 12:08:51 MHI-AC-Ctrl-Livingroom/OpData/PROTECTION-NO 0
Oct 28 12:08:53 MHI-AC-Ctrl-Livingroom/OpData/OU-FANSPEED 0
Oct 28 12:08:55 MHI-AC-Ctrl-Livingroom/OpData/DEFROST Off
Oct 28 12:08:59 MHI-AC-Ctrl-Livingroom/OpData/OU-EEV1 250
Oct 28 12:09:00 MHI-AC-Ctrl-Livingroom/set/Troom 19.8
Oct 28 12:09:00 MHI-AC-Ctrl-Livingroom/cmd_received o.k.
Oct 28 12:09:00 MHI-AC-Ctrl-Livingroom/Troom 19.75
Oct 28 12:09:05 MHI-AC-Ctrl-Livingroom/OpData/RETURN-AIR 19.75

So Troom 19.75 is set which returns Errorcode 0 and then Troom is set to 23,25 after which all OpData is posted. @absalom-muc what does Errorcode 0 signify?

OK, got another one, this time no error but the exact same behavior:

Oct 28 12:51:00 MHI-AC-Ctrl-Livingroom/set/Troom 20.0
Oct 28 12:51:00 MHI-AC-Ctrl-Livingroom/cmd_received o.k.
Oct 28 12:52:00 MHI-AC-Ctrl-Livingroom/Troom 23.75
Oct 28 12:52:02 MHI-AC-Ctrl-Livingroom/set/Troom 20.0
Oct 28 12:52:02 MHI-AC-Ctrl-Livingroom/cmd_received o.k.
Oct 28 12:52:02 MHI-AC-Ctrl-Livingroom/Troom 20.00

Seeing that the set command came after 62 seconds (10:52:02) I changed the

#define ROOM_TEMP_MQTT_SET_TIMEOUT  60              // time in seconds, after this time w/o receiving a valid room temperature
                                                    // via MQTT fallback to IU temperature sensor value

to

#define ROOM_TEMP_MQTT_SET_TIMEOUT  90              // time in seconds, after this time w/o receiving a valid room temperature
                                                    // via MQTT fallback to IU temperature sensor value

Will update of this helps

tomm1ed commented 1 year ago

So that indeed seens to fix it. If the update by Tasmota took even a microsecond longer than 60 seconds MHI-AC-CTRL defaulted back to the internal temperature and was then quickly updated again by Tasmota. Since changing the ROOM_TEMP_MQTT_SET_TIMEOUT to 90 around 13.15 no spikes at all and following the external Tempsensor perfectly:

mjszwo commented 1 year ago

I have the exact same issue with two Wemos D1. In my case, it does not matter if I let the aircon decide the room temperature, or if I push/force the temperature by MQTT. Changing the ROOM_TEMP_MQTT_SET_TIMEOUT value doesn't resolve anything in my setup.

Strange enough the spikes occur at TOPIC_TROOM, whilst TOPIC_RETURNAIR doesn't show the spikes at all. So I compared what is different between the two topics and I found this:

       case opdata_return_air:
        **case erropdata_return_air:**
          dtostrf((value - 61) / 4.0, 0, 2, strtmp);
          output_P(status, PSTR(TOPIC_RETURNAIR), strtmp);
          break;

        case status_troom:
          dtostrf((value - 61) / 4.0, 0, 2, strtmp);
          output_P(status, PSTR(TOPIC_TROOM), strtmp);
          break;

@absalom-muc ,is it possible that the spikes at TROOM will be resolved if 'case erropdata_troom:' is added, or am I thinking too simple?

absalom-muc commented 1 year ago

@mjszwo : Please provide a log of the serial debug output

mjszwo commented 1 year ago

@mjszwo : Please provide a log of the serial debug output

@absalom-muc, meanwhile I added my suggestion myself and I had no spikes for ~48 hours. This morning I flashed my Wemos again without the change and started logging. Here's the output where two spikes occured:

MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
status=136 topic=THI-R2 payload=56
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
status=143 topic=TD payload=<=30
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
mhi_ac_ctrl_core.loop error: -4
status=136 topic=THI-R2 payload=56
mhi_ac_ctrl_core.loop error: -4
status=143 topic=TD payload=<=30
mhi_ac_ctrl_core.loop error: -4
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Mode payload=Fan payload_length=3
status=64 topic=cmd_received payload=o.k.
status=65 topic=Mode payload=Fan
status=64 topic=Power payload=On
status=65 topic=Mode payload=Fan
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
mhi_ac_ctrl_core.loop error: -4
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Mode payload=Heat payload_length=4
status=64 topic=cmd_received payload=o.k.
status=65 topic=Mode payload=Heat
status=148 topic=unknown payload=4306
Unknown operating data, MOSI_frame[DB9]=210 MOSI_frame[D10]=16
status=130 topic=Tsetpoint payload=22.0
status=147 topic=OU-EEV1 payload=200
mhi_ac_ctrl_core.loop error: -4
status=148 topic=unknown payload=4306
Unknown operating data, MOSI_frame[DB9]=210 MOSI_frame[D10]=16
status=148 topic=unknown payload=4306
Unknown operating data, MOSI_frame[DB9]=210 MOSI_frame[D10]=16
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
status=141 topic=COMP payload=10.00
status=135 topic=THI-R1 payload=16
status=148 topic=unknown payload=4306
Unknown operating data, MOSI_frame[DB9]=210 MOSI_frame[D10]=16
status=136 topic=THI-R2 payload=55
status=138 topic=OU-FANSPEED payload=5
status=147 topic=OU-EEV1 payload=150
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
status=135 topic=THI-R1 payload=19
status=136 topic=THI-R2 payload=53
status=134 topic=IU-FANSPEED payload=1
status=132 topic=OUTDOOR payload=8.50
status=133 topic=THO-R1 payload=-4
status=68 topic=Troom payload=29.25
status=68 topic=Troom payload=21.25
status=141 topic=COMP payload=59.70
status=143 topic=TD payload=<=30
status=137 topic=THI-R3 payload=23
status=142 topic=CT payload=2.20
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
status=144 topic=TDSH payload=0
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
status=147 topic=OU-EEV1 payload=350
mhi_ac_ctrl_core.loop error: -4
status=135 topic=THI-R1 payload=26
status=136 topic=THI-R2 payload=45
status=134 topic=IU-FANSPEED payload=8
status=132 topic=OUTDOOR payload=8.75
status=133 topic=THO-R1 payload=-2
status=141 topic=COMP payload=44.70
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
status=143 topic=TD payload=<=30
status=137 topic=THI-R3 payload=26
status=142 topic=CT payload=1.65
status=144 topic=TDSH payload=1
mhi_ac_ctrl_core.loop error: -4
status=147 topic=OU-EEV1 payload=317
mhi_ac_ctrl_core.loop error: -4
status=135 topic=THI-R1 payload=25
status=136 topic=THI-R2 payload=51
MQTT_subscribe_callback, topic=MHI-AC-Ctrl-US/us/set/Troom payload=21.25 payload_length=5
ROOM_TEMP_MQTT: 21.250000 146 146
status=64 topic=cmd_received payload=o.k.
status=132 topic=OUTDOOR payload=9.00
status=133 topic=THO-R1 payload=-1

And here a screenshot of the spike. I suspect the first little spike to be the non-MQTT temperature because of the reboot. But the second spike is the one that occurs randomly.

mhi_ac_ctrl_spike

tomm1ed commented 1 year ago

@absalom-muc / @mjszwo for what it’s worth since upgrading to 2.6R2 with the 90 second timeout I have had zero spikes:

absalom-muc commented 1 year ago

I can't imagine that your problem is related to 'case erropdata_troom'. As far as I know erropdata_troom doesn't exist.

If you used so far 80MHz for CPU frequency, you could test if the number of "mhi_ac_ctrl_core.loop error: -4"-messages is reduced by applying 160MHz.

If it doesn't help please provide the log file in the way I described here (added few hours ago), especially the time stamp should be enabled. Addtionally please provide the following information:

mjszwo commented 1 year ago

I have been running the Wemos on 160MHz for +48 hours, and no spikes occured within that period. So it seems that this fixed it.