Vanes left/right swing and mode #10

b0rder · 2020-04-21T08:39:15Z

Hi,

I've successfully connected SRK25ZJ-S to Wemos D1 using this great project.

Just a few notes:

Pinout of MHI CNS connector was different from which described in this project (CLK and MOSI should be swapped). So, my CNS connector pinout: +12V, SPI_CLK, SPI_MOSI, SPI_MISO, GND.
After flashing ESP8266 with sketch I have a lot of messages "Wrong MOSI signature". That's because ESP8266 CPU speed was not enough (80MHz). After flashing with CPU speed 160MHz it works like a charm.

I've started to investigate SPI bus protocol according, and found there is nothing about changing Vanes left/right position and mode. Unfortunately I have no wired module to sniff set commands for this operation. Also, the latest status is not changed during operation using IR as well (the same logic as for vanes up/down swing).

If You have wired remote, can You catch the commands during such operations? Probably we can extend SPI bus interface description and then to implement additional commands?

Thanks.

The text was updated successfully, but these errors were encountered:

absalom-muc · 2020-04-22T19:07:13Z

Hi,

I've successfully connected SRK25ZJ-S to Wemos D1 using this great project.

Thank you for your feedback.

Just a few notes:

1. Pinout of MHI CNS connector was different from which described in this project (CLK and MOSI should be swapped). So, my CNS connector pinout: +12V, SPI_CLK, SPI_MOSI, SPI_MISO, GND.

I believe that is in sync with the description

2. After flashing ESP8266 with sketch I have  a lot of messages "Wrong MOSI signature". That's because ESP8266 CPU speed was not enough (80MHz). After flashing with CPU speed 160MHz it works like a charm.

That is interesting - thank you! Which SCL frequency is output?

I've started to investigate SPI bus protocol according, and found there is nothing about changing Vanes left/right position and mode. Unfortunately I have no wired module to sniff set commands for this operation. Also, the latest status is not changed during operation using IR as well (the same logic as for vanes up/down swing).

If You have wired remote, can You catch the commands during such operations? Probably we can extend SPI bus interface description and then to implement additional commands?

Unfortunatelly the wired remote control (I used two different devices) doesn't support vanes left/right. I assume it is in general not supported by the SPI

b0rder · 2020-04-23T18:00:25Z

Just a few notes:

1. Pinout of MHI CNS connector was different from which described in this project (CLK and MOSI should be swapped). So, my CNS connector pinout: +12V, SPI_CLK, SPI_MOSI, SPI_MISO, GND.

I believe that is in sync with the description

This point is a little bit confuse me. According to the schematic PIN2 (SCL?) connected to D7 (GPIO13) and PIN3 (MOSI?) connected to D5 (GPIO14) description.
But according to source code:

#define SCK 14
#define MOSI 13
#define MISO 12

I think there is a type in schematic.

2. After flashing ESP8266 with sketch I have  a lot of messages "Wrong MOSI signature". That's because ESP8266 CPU speed was not enough (80MHz). After flashing with CPU speed 160MHz it works like a charm.

That is interesting - thank you! Which SCL frequency is output?

I didn't use analyzer, but according console output values are not stable (SCKf=5.3kHz...18kHz, MOSIf=0.8...2.5kHz):

SCK frequency=5304Hz (expected: >3000Hz) 
MOSI frequency=759Hz (expected: <SCK frequency) 
SCK frequency=7928Hz (expected: >3000Hz) 
MOSI frequency=1118Hz (expected: <SCK frequency) 
MOSI frequency=1474Hz (expected: <SCK frequency) 
SCK frequency=13077Hz (expected: >3000Hz) 
MOSI frequency=1819Hz (expected: <SCK frequency) 
SCK frequency=13077Hz (expected: >3000Hz) MOSI frequency=1819Hz (expected: <SCK frequency) 
SCK frequency=18253Hz (expected: >3000Hz) 
MOSI frequency=2539Hz (expected: <SCK frequency)

That's output from a working sketch on 160MHz esp8266 CPU.

I've started to investigate SPI bus protocol according, and found there is nothing about changing Vanes left/right position and mode. Unfortunately I have no wired module to sniff set commands for this operation. Also, the latest status is not changed during operation using IR as well (the same logic as for vanes up/down swing).
If You have wired remote, can You catch the commands during such operations? Probably we can extend SPI bus interface description and then to implement additional commands?

Unfortunatelly the wired remote control (I used two different devices) doesn't support vanes left/right. I assume it is in general not supported by the SPI

I think the situation with up/down vanes was the same as for left/right:

note: Vanes status is not applicable when using IR remote control. The latest vanes status is only visible when it was changed by the SPI-RC. The latest vanes status is only visible when MOSI DB0[7]=1 or MOSI DB1[7]=1.

Also, I have a lot of messages like:
Troom 27.25
...
Troom 24.50

It looks like temperature sensor is not precise, and to avoid very frequent temperature change reporting, I changed:
if (updateMQTTStatus | (abs(troom_diff) > 1)) { // Room temperature delta > 0.25°C
to
if (updateMQTTStatus | (abs(troom_diff) > 10)) { // Room temperature delta > 0.25°C (2°C)

And a last question: why You didn't use SPI.h library from Arduino to work with this stuff?

absalom-muc · 2020-04-24T06:33:44Z

For the connection of the air conditioner with the MHI-AC-Ctrl PCB we have the following situation:

That means when using the MHI-AC-Ctrl PCB the connection cable has to swap MOSI and SCL. Maybe it is a good idea to add this diagram to the description to make it clearer.

And a last question: why You didn't use SPI.h library from Arduino to work with this stuff?

Originally when I started with the hardware SPI from ESP8266 and using the Arduino stuff. I managed to use the RX path with the HW SPI (see here). But I found no way to transmit data synchronously to the receive data with the HW SPI. Therefore I use the SW SPI.

I think the situation with up/down vanes was the same as for left/right

I have no idea how to find out the SPI control sequence for vanes left/right, if it exists.

Related to the other topics I will come back to you later.

absalom-muc · 2020-04-24T09:12:39Z

It seems that your SRK xx ZJ-S uses a higher SCK frequency than my SRK xx ZS-S. Where you see SCKf=5.3kHz...18kHz, I see more or less constant fsck=3200Hz. I can imagine that the SW SPI can't manage your high SCK frequencies when running at 80MHz. Therefore, switching the CPU to 160MHz was a good idea.
But it still seems that it works not really stable because of the SCK frequency variations (it should be a constant value and not always changing).
Maybe the toggling Troom temperature values is related to this instability. The temperature sensor of the indoor unit might not be accurate, but it should provide stable values when there is no temperature change. My AC provides stable values. I observe toggling of the least significant bit only, that is related to 0.25°C.

Summarized I assume we can improve the MHI-AC-Ctrl for your AC but it will be some effort on my side and on your side for testing. I am o.k. to spend this time, but before I start with further evaluations, please give me feedback if you are interested to improve it and if you are willing to make some tests.

b0rder · 2020-04-24T21:15:26Z

It seems that your SRK xx ZJ-S uses a higher SCK frequency than my SRK xx ZS-S. Where you see SCKf=5.3kHz...18kHz, I see more or less constant fsck=3200Hz. I can imagine that the SW SPI can't manage your high SCK frequencies when running at 80MHz. Therefore, switching the CPU to 160MHz was a good idea.

I'll try to get frequency analyser to measure frequency of PIN2 (SCL) directly on MHI...

But it still seems that it works not really stable because of the SCK frequency variations (it should be a constant value and not always changing).

Even it is not really stable, I don't notice that :) It works :)
Probably, there is something wrong when ESP measures freauency, but I am not sure. That's why I want to measure SCL with frequency analyzer.

Maybe the toggling Troom temperature values is related to this instability. The temperature sensor of the indoor unit might not be accurate, but it should provide stable values when there is no temperature change. My AC provides stable values. I observe toggling of the least significant bit only, that is related to 0.25°C.

Tha'ts really strange. One more thing I noticed, few years ago my SRK25ZJ-S stops produce beep sound (when I start/stop power, or when I change mode in cycle). I don't know can it be related somehow with SCK stability, but I hope there is some problem with buzzer (or contacts on board, but I am not sure).

Summarized I assume we can improve the MHI-AC-Ctrl for your AC but it will be some effort on my side and on your side for testing. I am o.k. to spend this time, but before I start with further evaluations, please give me feedback if you are interested to improve it and if you are willing to make some tests.

Yes, I am ready to make some tests.

absalom-muc · 2020-04-26T05:53:55Z

Perfect, then let us start with the frequency measurement.
f_measurement.txt
Since it is not supported to attach .ino-files I renamed it to .txt. So, please rename it back to f_measurement.ino, run it for approx. 1 minute and provide the log file from the serial output. (preferred as an attachment ending with .log).
If you see that the SCK results are not stable, please comment out the MOSI and MISO related stuff in line 44,45,50,51 and 57,58 and make a second run.
Addtionally provide a log of MHI-AC-Ctrl for 1 minute after reset (the AC should be power off)
Thank you.

b0rder · 2020-04-27T08:09:00Z

I performed test using provided f_measurement.ino. I didn't change it.
Results for run at 160MHz CPU:
measurement_160.log
Results for run at 80MHz CPU (AC power on):
measurement_80.log
Results for run at 80MHz CPU (AC power ON, then power OFF, then power ON):
measurement_80_on_off_on.log

SCK frequency seems to be stable - 2.5-2.7kHz now :)

absalom-muc · 2020-04-28T18:27:35Z

Perfect, thank you! Originally I believed that SCK of your AC has a higher frequency than my AC. But now it is visible that SCK=2720Hz only. That may mean that more time is consumed for receiving a frame, so there is less time left for publishing MQTT data.
Could you make another test? Please add the following line to row 378:

   Serial.println("f");  // <- please insert his line
    if (((rx_SPIframe[SB0] & 0xfe) == 0x6c) & (rx_SPIframe[SB1] == 0x80) & (rx_SPIframe[SB2] == 0x04) & ((rx_SPIframe[CBH]<<8 | rx_SPIframe[CBL]) == rx_checksum)) {
      valid_datapacket_received = true;
    }

and enable "show timestamp" of the serial monitor. Please log it for 1 minute during power off. And another log when power on.
Thank you!

b0rder · 2020-04-28T19:08:24Z

Serial output during power off (first power off AC, then start serial logging):
test_poff.log
Serial output during power on (first power on AC, then start serial logging):
test_pon.log

And some additional logging of MQTT:
First power off AC, then start MQTT logging:
test_mqtt_poff.log
First power on AC, then start MQTT logging, after ~1min AC powered OFF, then stops logging:
test_mqtt_pon.log

Some notes about test. When AC on, it is started in HEAT mode.
For MQTT logging, first lines are retained messages (some of them was from my tests and left in mqtt broker).

Just for info command which I used to store MQTT log:
mosquitto_sub -t '/mhi/#' -u *** -P *** -v |ts '%Y%m%d-%H:%M:%.S' |tee /tmp/test_mqtt_pon.log

absalom-muc · 2020-04-29T18:29:59Z

o.k. thank you. Will check it and come back to you

absalom-muc · 2020-05-02T19:09:24Z

I have another (most probably last) test. Please run for ~1 minute and send me the log.
frame_measurement_0.4.txt

b0rder · 2020-05-03T20:26:15Z

I performed run more then ~1minute:
Run when AC is off.
23:12:27 - AC switched on (ventilator mode)
23:13:25 - AC switched to auto mode
23:15:03 - AC switched to cool mode
23:20:00 - AC switched on
Result in attachment.
frame_measurement_0.4.log

absalom-muc · 2020-05-08T06:46:12Z

Thank you b0rder, I'm still checking it and come back to you ...

absalom-muc · 2020-05-12T22:00:44Z

When comparing the SPI timing

AC	T_Frame	T_FramePause	T_Byte	T_BytePause	T_Bit
SRK xx ZS-S	10ms	40ms	250µs	250µs	31.25µs
SRK xx ZJ-S	10ms	44ms	120µs	360µs	15µs

the main difference is the doubling of the bit frequency. Overall the measurement was very unstable. I do not know the reason, maybe the cable between AC and MHI-AC-Ctrl is too long. However, since this does not create a problem, we should make no further efforts.

I had also deeper look on your logs here. I have no idea why there are so many temperature changes reported. The SPI connection to the AC is stable (only few async messages). It seems to be something different or wrong with your AC. Sorry, but I don't know how to improve it.

b0rder · 2020-05-13T12:43:48Z

Cable length between AC and ESP about 15cm (30AWG for data and 24AWG for power lines).
I think the difference due to model SRK xx ZJ-S (which is the old model, replaced by SRK xx ZS-S).
One thing left unresolved for my model, is the temperature event handling. I found this part of code where you count packet repetition, and I think because for my AC each packet has temperature deviation > 0.25C, repetitionNo always=1 or 2:

code:

            if (updateMQTTStatus | (abs(troom_diff) > 1)) { // Room temperature delta > 0.25°C
                troom_old = rx_SPIframe[DB3];
                float troom = (float)(troom_old - 61) / 4.0;
                dtostrf(troom, 0, 2, strtmp);
                Serial.printf("Troom=%s repetitionNo=%u packet_cnt=%u\r\n", strtmp, repetitionNo, packet_cnt);
            }

output:

Troom=27.25 repetitionNo=1 packet_cnt=41
Troom=29.50 repetitionNo=1 packet_cnt=42
Troom=30.25 repetitionNo=1 packet_cnt=45
Troom=28.50 repetitionNo=1 packet_cnt=46
Troom=26.00 repetitionNo=1 packet_cnt=47
Troom=25.50 repetitionNo=1 packet_cnt=48
Troom=27.75 repetitionNo=1 packet_cnt=51
Troom=25.00 repetitionNo=1 packet_cnt=52
Troom=27.50 repetitionNo=2 packet_cnt=55
Troom=25.00 repetitionNo=1 packet_cnt=57
Troom=28.75 repetitionNo=1 packet_cnt=58
Troom=25.50 repetitionNo=1 packet_cnt=59
Troom=26.00 repetitionNo=2 packet_cnt=61
Troom=27.25 repetitionNo=1 packet_cnt=62

Probably, I need to add some preprocessing of temperature change event to calculate average (for example, once per minute) and then publish that value via MQTT if there is difference with previous value.

absalom-muc · 2020-05-13T20:31:20Z

Cable lenght sounds not critical in your case. I use cables with the doubled length.
Do you have the same effect with the other temperatur measurements, i.e. the return temperature or the outdoor temperature of the operating data?
You can use the return temperature as reference (when AC is off) to check if the average temperature is the right value.

b0rder · 2020-05-15T14:36:09Z

One more thing I found with my AC. Sometimes I have messages:
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35

After I increased lastDatapacketMillis threshold from 35 to 200, sync error messages disappeared (sync=1 and sync=0). Looks like work stable. Is it right thing to do that? Or it is better to leave 35ms?
Once I have message regarding wrong signature like this:
Wrong MOSI signature: 0x04 0x50 0x00 or checksum received!
04 50 00 2E A1 00 00 88 00 FF FF FF FF FF 00 00 07 92 6C
But this was only once, and probably I will debug message data manually later (if signature message will repeat).

To avoid flood with Troom messages, I've modified code to show temperature change messages once per 30 seconds like this:

            int8_t troom_diff = rx_SPIframe[DB3] - troom_old; // avoid using other functions inside the brackets of abs, see https://www.arduino.cc/reference/en/language/functions/math/abs/
            if (updateMQTTStatus | (abs(troom_diff) > 1 & lastDatapacketMillis-lastTroomMillis > 30000 )) { // Room temperature delta > 0.25°C
                lastTroomMillis = lastDatapacketMillis;
                troom_old = rx_SPIframe[DB3];
                float troom = (float)(troom_old - 61) / 4.0;

After that console log for events looks very promising (yes, I am on the way to integrate your code in Tasmota framework):

17:12:08 APP: Boot Count 63
17:12:09 RSL: tele/tasmota_4B0746/STATE = {"Time":"2020-05-15T17:12:09","Uptime":"0T00:00:11","UptimeSec":11,"Vcc":2.982,"Heap":29,"SleepMode":"Dynamic","Sleep":0,"LoadAvg":716,"MqttCount":0,"Wifi":{"AP":1,"SSId":"***","BSSId":"***","Channel":6,"RSSI":42,"Signal":-79,"LinkCount":1,"Downtime":"0T00:00:05"}}
17:12:09 CFG: Saved to flash at F5, Count 103, Bytes 4096
17:12:10 RSL: tele/tasmota_4B0746/IU-FANSPEED = 0
17:12:13 RSL: tele/tasmota_4B0746/TOTAL-IU-RUN = 1700
17:12:15 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.75
17:12:17 RSL: tele/tasmota_4B0746/COMP = 0.00
17:12:20 RSL: tele/tasmota_4B0746/OUTDOOR = 15.75
17:12:22 RSL: tele/tasmota_4B0746/CT = 0
17:12:25 RSL: tele/tasmota_4B0746/TDSH = 15
17:12:27 RSL: tele/tasmota_4B0746/PROTECTION-NO = 0
17:12:29 RSL: tele/tasmota_4B0746/TROOM = 25.25
17:12:30 RSL: tele/tasmota_4B0746/OU-FANSPEED = 0
17:12:32 RSL: tele/tasmota_4B0746/DEFROST = Off
17:12:34 RSL: tele/tasmota_4B0746/TOTAL-COMP-RUN = 1500
17:12:39 RSL: tele/tasmota_4B0746/SYNCED = 0
17:12:39 RSL: tele/tasmota_4B0746/SYNCED = 1
17:12:49 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.50
17:12:54 RSL: tele/tasmota_4B0746/OUTDOOR = 15.50
17:12:59 RSL: tele/tasmota_4B0746/TROOM = 26.00
17:13:23 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.25
17:13:29 RSL: tele/tasmota_4B0746/TROOM = 24.75
17:13:59 RSL: tele/tasmota_4B0746/TROOM = 25.50
17:14:03 RSL: tele/tasmota_4B0746/OUTDOOR = 15.75
17:14:27 RSL: tele/tasmota_4B0746/SYNCED = 0
17:14:27 RSL: tele/tasmota_4B0746/SYNCED = 1
17:14:29 RSL: tele/tasmota_4B0746/TROOM = 25.00
17:14:32 RSL: tele/tasmota_4B0746/RETURN-AIR = 26.00
17:14:59 RSL: tele/tasmota_4B0746/TROOM = 25.75
17:15:07 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.50
17:15:29 RSL: tele/tasmota_4B0746/TROOM = 24.50
17:15:41 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.75
17:15:46 RSL: tele/tasmota_4B0746/OUTDOOR = 16.00
17:15:59 RSL: tele/tasmota_4B0746/TROOM = 25.50
17:16:15 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.50
17:16:30 RSL: tele/tasmota_4B0746/TROOM = 24.75
17:16:49 RSL: tele/tasmota_4B0746/RETURN-AIR = 26.00
17:17:00 RSL: tele/tasmota_4B0746/TROOM = 25.25
17:17:09 RSL: tele/tasmota_4B0746/STATE = {"Time":"2020-05-15T17:17:09","Uptime":"0T00:05:11","UptimeSec":311,"Vcc":2.983,"Heap":28,"SleepMode":"Dynamic","Sleep":0,"LoadAvg":6000,"MqttCount":0,"Wifi":{"AP":1,"SSId":"***","BSSId":"***","Channel":6,"RSSI":42,"Signal":-79,"LinkCount":1,"Downtime":"0T00:00:05"}}
17:17:23 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.50
17:17:30 RSL: tele/tasmota_4B0746/TROOM = 26.00
17:17:57 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.75
17:18:00 RSL: tele/tasmota_4B0746/TROOM = 23.75
17:18:30 RSL: tele/tasmota_4B0746/TROOM = 24.75
17:18:31 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.25
17:18:36 RSL: tele/tasmota_4B0746/OUTDOOR = 15.75
17:19:00 RSL: tele/tasmota_4B0746/TROOM = 26.25
17:19:30 RSL: tele/tasmota_4B0746/TROOM = 24.75
17:19:39 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.75
17:20:00 RSL: tele/tasmota_4B0746/TROOM = 23.50
17:20:02 CMD: sleep
17:20:02 SRC: WebConsole from 192.168.***
17:20:02 CMD: Group 0, Index 1, Command "SLEEP", Data ""
17:20:02 RSL: stat/tasmota_4B0746/RESULT = {"Sleep":{"0":{"Active":"0"}}}
17:20:04 CMD: sleep 50
17:20:04 SRC: WebConsole from 192.168.***
17:20:04 CMD: Group 0, Index 1, Command "SLEEP", Data "50"
17:20:04 RSL: stat/tasmota_4B0746/RESULT = {"Sleep":{"50":{"Active":"50"}}}
17:20:05 CFG: Saved to flash at F4, Count 104, Bytes 4096
17:20:13 RSL: tele/tasmota_4B0746/RETURN-AIR = 27.00
17:20:30 RSL: tele/tasmota_4B0746/TROOM = 24.75
17:20:47 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.75
17:20:53 RSL: tele/tasmota_4B0746/OUTDOOR = 15.50
17:21:00 RSL: tele/tasmota_4B0746/TROOM = 25.75
17:21:15 RSL: tele/tasmota_4B0746/SYNCED = 0
17:21:15 RSL: tele/tasmota_4B0746/SYNCED = 1
17:21:22 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.25
17:21:30 RSL: tele/tasmota_4B0746/TROOM = 26.50
17:21:56 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.50
17:22:00 RSL: tele/tasmota_4B0746/TROOM = 24.75
17:22:09 RSL: tele/tasmota_4B0746/STATE = {"Time":"2020-05-15T17:22:09","Uptime":"0T00:10:11","UptimeSec":611,"Vcc":2.983,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":119,"MqttCount":0,"Wifi":{"AP":1,"SSId":"***","BSSId":"***","Channel":6,"RSSI":48,"Signal":-76,"LinkCount":1,"Downtime":"0T00:00:05"}}
17:22:30 RSL: tele/tasmota_4B0746/TROOM = 25.50
17:22:30 RSL: tele/tasmota_4B0746/RETURN-AIR = 25.75
17:22:35 RSL: tele/tasmota_4B0746/OUTDOOR = 15.25
17:23:00 RSL: tele/tasmota_4B0746/TROOM = 24.50
17:23:04 RSL: tele/tasmota_4B0746/RETURN-AIR = 26.25
17:23:09 RSL: tele/tasmota_4B0746/OUTDOOR = 15.50
17:23:30 RSL: tele/tasmota_4B0746/TROOM = 25.25
17:23:39 RSL: tele/tasmota_4B0746/RETURN-AIR = 26.75
17:24:01 RSL: tele/tasmota_4B0746/TROOM = 24.50
17:24:14 RSL: tele/tasmota_4B0746/RETURN-AIR = 26.25
17:24:19 RSL: tele/tasmota_4B0746/OUTDOOR = 15.25
17:24:31 RSL: tele/tasmota_4B0746/TROOM = 25.00
17:24:48 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.75
17:25:01 RSL: tele/tasmota_4B0746/TROOM = 25.75
17:25:05 RSL: tele/tasmota_4B0746/SYNCED = 0
17:25:05 RSL: tele/tasmota_4B0746/SYNCED = 1
17:25:23 RSL: tele/tasmota_4B0746/RETURN-AIR = 26.25
17:25:31 RSL: tele/tasmota_4B0746/TROOM = 24.25
17:25:57 RSL: tele/tasmota_4B0746/RETURN-AIR = 24.00
17:26:01 RSL: tele/tasmota_4B0746/TROOM = 26.00

absalom-muc · 2020-05-15T18:29:17Z

One more thing I found with my AC. Sometimes I have messages:
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35
async: millis() - lastDatapacketMillis > 35

After I increased lastDatapacketMillis threshold from 35 to 200, sync error messages disappeared (sync=1 and sync=0). Looks like work stable. Is it right thing to do that? Or it is better to leave 35ms?
Once I have message regarding wrong signature like this:
Wrong MOSI signature: 0x04 0x50 0x00 or checksum received!
04 50 00 2E A1 00 00 88 00 FF FF FF FF FF 00 00 07 92 6C
But this was only once, and probably I will debug message data manually later (if signature message will repeat).

The message "async: millis() - lastDatapacketMillis > 35" informs you that you loose the SPI synchronization, because the program execution between 2 frames took more than 35ms. If you loose the synchronization you will have more messages "Wrong MOSI signature ..."
With increasing the 35 to 200 you suppress the warning, but if you can still use the program to control the AC I see no issue.

According the log also RETURN-AIR is not stable, I have no explanation for this behavior. So, your work around seems to appropriate.

absalom-muc · 2020-06-24T10:48:49Z

@b0rder Could you run the SPI logger and provide the log? That would be helpful to understand the differences in the SPI protocol.

absalom-muc · 2020-08-09T17:28:50Z

If you are still interested in a follow up, please feel free to re-open this issue

absalom-muc mentioned this issue Jun 20, 2020

Add supported MHI models #17

Closed

makonrus mentioned this issue Jun 22, 2020

Problem with SRK25ZJX-S #21

Closed

absalom-muc closed this as completed Aug 9, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Vanes left/right swing and mode #10

Vanes left/right swing and mode #10

b0rder commented Apr 21, 2020 •

edited

Loading

absalom-muc commented Apr 22, 2020

b0rder commented Apr 23, 2020

absalom-muc commented Apr 24, 2020 •

edited

Loading

absalom-muc commented Apr 24, 2020 •

edited

Loading

b0rder commented Apr 24, 2020 •

edited

Loading

absalom-muc commented Apr 26, 2020 •

edited

Loading

b0rder commented Apr 27, 2020

absalom-muc commented Apr 28, 2020

b0rder commented Apr 28, 2020 •

edited

Loading

absalom-muc commented Apr 29, 2020

absalom-muc commented May 2, 2020

b0rder commented May 3, 2020

absalom-muc commented May 8, 2020

absalom-muc commented May 12, 2020

b0rder commented May 13, 2020

absalom-muc commented May 13, 2020

b0rder commented May 15, 2020

absalom-muc commented May 15, 2020 •

edited

Loading

absalom-muc commented Jun 24, 2020

absalom-muc commented Aug 9, 2020

Vanes left/right swing and mode #10

Vanes left/right swing and mode #10

Comments

b0rder commented Apr 21, 2020 • edited Loading

absalom-muc commented Apr 22, 2020

b0rder commented Apr 23, 2020

absalom-muc commented Apr 24, 2020 • edited Loading

absalom-muc commented Apr 24, 2020 • edited Loading

b0rder commented Apr 24, 2020 • edited Loading

absalom-muc commented Apr 26, 2020 • edited Loading

b0rder commented Apr 27, 2020

absalom-muc commented Apr 28, 2020

b0rder commented Apr 28, 2020 • edited Loading

absalom-muc commented Apr 29, 2020

absalom-muc commented May 2, 2020

b0rder commented May 3, 2020

absalom-muc commented May 8, 2020

absalom-muc commented May 12, 2020

b0rder commented May 13, 2020

absalom-muc commented May 13, 2020

b0rder commented May 15, 2020

absalom-muc commented May 15, 2020 • edited Loading

absalom-muc commented Jun 24, 2020

absalom-muc commented Aug 9, 2020

b0rder commented Apr 21, 2020 •

edited

Loading

absalom-muc commented Apr 24, 2020 •

edited

Loading

absalom-muc commented Apr 24, 2020 •

edited

Loading

b0rder commented Apr 24, 2020 •

edited

Loading

absalom-muc commented Apr 26, 2020 •

edited

Loading

b0rder commented Apr 28, 2020 •

edited

Loading

absalom-muc commented May 15, 2020 •

edited

Loading