StandBy/Full with esp8266

[supersjimmie]

As you might probably remember, I have this stuff running on an esp2866 since a long time.
The past few days I tried to catch up with you by adding the StandBy and Full to my code too.
However the esp crashes when I try rft_fullpower or rft_standby.
After some tracing, I found that this is the problem:
uint8_t* IthoCC1101::getMessage1CommandBytes(IthoCommand command)
returns the "default" of 0 when the command is either Standby or Full, simply because there are no ithoMessage1HighCommandBytes for Standby/Full.

The next step is then:
packet->data[9] = packet->data[9] | commandBytes[0]; //only last bit is set
Where the esp crashes. (commandBytes is empty, so there is no commandBytes[0])

[Klusjesman]

There is no need to send message1. The fan will work when only message2 is used. In the lastest version of the code I am not sending message1. This is why getMessage1CommandBytes was not updated.
You can remove the call to createMessageStart to skip sending message1 (see latest IthoCC1101.cpp).

If I remember correctly, there was a difference between message1 of the ecofan and the duco and I decided to leave it out.

[supersjimmie]

You're right. Just after posting my message, I was thinking about that too.
The call to createMessageStart in sendCommand was obsolete but I forgot to remove it.
Going to test further. Thanks again @Klusjesman !

[supersjimmie]

However, my itho (still) responds strange to the standby/full commands.
Instead of blowing very low or full, it goes into some kind of interval mode.
17sec silence and then a short 3sec spin-up and then back to 17sec silence, etcetera...

[Klusjesman]

Are you using your own device ID or the one from my code? I extracted the command bytes from a duco remote message (I bought one). When I implemented the standby and full commands I only tested them with my own RF setup and device ID.

[supersjimmie]

Yep, I'm still using your device ID.

I've gone through all past commits on your code, and comparing every change one-by-one with my code (has to do this manually because my complete code differs on several other parts). There are no relevant differences.

The only thing I can think about is that my fan itself doesn't support those modes.

[supersjimmie]

Just one question to clarify things for me.
You use the rft ID and rft_standby / rft_fullpower, right?
So all 'duco' related items are actually unused for sending (only used for receiving)?

I ask this because I basically copy/pasted all your code back into mine and made only the changes that are needed for my esp8266, and it still only goes into an interval style with standby and full. :(

[Klusjesman]

I would have to do some tests to verify if my code on github is ok. My RF setup is still laying on my desk so it shouldn't take too much time. I will try to have a look at it coming days.

[supersjimmie]

Don't bother too much. When the first attempts for standby and full came online (at tweakers), I also did one attempt with the tx-codes that were shared there and that too resulted in only intervals on my itho.
But if it's possible for you to do some short test, it would be nice. :)

[supersjimmie]

In the mean time, I've heard from one other person that the full (and most likely the standby) works fine at his system.

[Klusjesman]

Do you want to test with the Duco remote yourself? The remote has a button for the standby command. I can send it to you if you want to investigate.

[supersjimmie]

I think I still have your email address...

[rplevka]

@supersjimmie

17sec silence and then a short 3sec spin-up and then back to 17sec silence, etcetera...

given the date you posted it, I would assume this was the unit's built-in anti-freezing mode. if the temperature of the intake air drops under certain level (-5 celsius?) it works like this.
I tested the standby/full on my own and it works flawlessly

@Klusjesman

I extracted the command bytes from a duco remote message (I bought one)

How could I extract the id of my own RFT remote?
sorry, i'm completely unexperienced - would you mind sharing the code snippet?
i use your code as-is and it works, i'm just not getting any messages from other (official remote) - I guess it's because the id differs. I'd like to listen to the units and other remotes messages in order to keep my setup in sync (i want to publish MQTT messages).

thanks for all your work!

[Klusjesman]

Hi,

I walked through the code and I do not see any checks on device id. So I think it should be possible to receive messages from other devices without any changes. Maybe supersjimmie can confirm since he ported my code and used his own device id. I don't remember exactly since it was a few years ago. I used a serial analyzer to reverse engineer all SPI commands and messages.

In the checkForNewPacket in IthoCC1101 it is checking the buffer if there is a new message. Itho uses
two messages. We only need message 2. My code is set up to expect message 1 first. This first message is parsed in parseMessageStart. You should be able to write the received device id to a debug port in this function. After messages 1 is parsed the code programs the CC1101 to be able to receive message 2.

What I remember from using different device id is that the calculateMessagexxx functions will be different. The calculations are partially based on the device id. But this is for sending only. I never spend time on it to find out how it works.