Can send only one command, and no reaction with next ones

[tparvais]

Hello

I compile your plugin with last ESP8266 2.4.2 libraries. It works (except others RF discovery)

But I can obly send one command. the ITHO does not react to others command http://192.168.0.55/control?cmd=STATE,3 OK then go down: http://192.168.0.55/control?cmd=STATE,1 NOK

I tried with 2 different ESP8266 and 2 different CC1101 module. same result

Sorry to get help via this method, I could not get feedback from the forum

Thank you very much

Thomas

[supersjimmie]

With "only ne command" you mean that you can only send the speed 3 and not 1 or 2? (So you send 3, then manually return your fan to 1 and you can send 3 again) Or do you mean only the first command you send is accepted? (whichever 1, 2 or 3 is sent first, only the one sent first is accepted)

Perhaps it would also help if you share your code, including the source of your "plugin", because I have only written the library and other people made some plugins.

[tparvais]

Hello

Thank you for feedback. Strangely, from state1, sending control?cmd=STATE,3 works once. but if after I send control?cmd=STATE,2 or control?cmd=STATE,1, it does not go down.

My RFswitches ITHO still working fine

The plugin is coming from ESPEASY GIThub and libraries I used are attached

Many thank you

PS: interrupt to detect message from RF command has never worked for me. ESPEasy-TPA.zip

[tparvais]

Very strangely, I even cannot send anymore any command from ESP8266 to ITHO. Even state,3 does not work (after itho reboot etc...). I tried another join procedure but no effect. I have tried with 2 different ESP+CC1101. I don't understand why it was working few days ago and not anymore now. I tried many different codes & itho libraries. The last one is your library from github with ESPeasy plugin 0145.

Is there a procedure to clean the ITHO memory maybe ?

[supersjimmie]

Perhaps you can make 2 sets with esp+cc1101? Then you can see if one receives the other.

[supersjimmie]

@tparvais by the way, are you sure(...) that the cc1101 is not a cc1105 and it is a 868MHz version and not 433MHz?

[tparvais]

Yes as it worked before . Very strange

Thomas

Le 23 août 2018 à 13:22, supersjimmie notifications@github.com a écrit :

@tparvais by the way, are you sure(...) that the cc1101 is not a cc1105 and it is a 868MHz version and not 433MHz?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[tparvais]

Maybe you will see something wrong I cannot see myself ?

Thomas

Le 23 août 2018 à 13:22, supersjimmie notifications@github.com a écrit :

@tparvais by the way, are you sure(...) that the cc1101 is not a cc1105 and it is a 868MHz version and not 433MHz?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[supersjimmie]

If you are so sure that everything is fine, just because "it worked before", how could I then find any issue? Please check as I suggested to rule out missing things. Check the cc1101 including its frequency (a 443 version might sometimes work a little bit). Go back to the working code here on github, use the unmodified library and .ino file, join, check.

Then create 2 sets, one should receive the other.

Also don't change anything even if it seems not important (like the irq or device codes).

Finally, use soldered wires and keep them very-very short.

[tparvais]

You’re right . I’ll try to redo everything from scratch including soldering and compiling from your original library .

To be sure I”m using right cc 1101 module can you tell me you purchased yours ? This is maybe the reason why I didn’t get rf. y listening

Many thanks anyway

Thomas

Le 23 août 2018 à 13:46, supersjimmie notifications@github.com a écrit :

If you are so sure that everything is fine, just because "it worked before", how could I then find any issue? Please check as I suggested to rule out missing things. Check the cc1101 including its frequency (a 443 version might sometimes work a little bit). Go back to the working code here on github, use the unmodified library and .ino file, join, check.

Then create 2 sets, one should receive the other.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[supersjimmie]

perhaps you can place a picture of yours? I bought several from ebay and aliexpress. (pic including a clear reading of the metal crystal)

[tparvais]

Here it is

Thomas

Le 23 août 2018 à 13:53, supersjimmie notifications@github.com a écrit :

perhaps you can place a picture of yours? I bought several from ebay and aliexpress.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[supersjimmie]

Sorry, not vissible on github.

[tparvais]

here it is

[tparvais]

[tparvais]

Hello https://github.com/incmve/Itho-WIFI-remote works perfectly includign its library. I tried to compare this library with yours and there are changes in the CC1101 modem configuration and the way packets are sent. Not very clear for me.

I adapt code of the plugin to work with the library of INCMVE and now it works fine (1/2/3 / timer1). I remember I did that several days ago already , but as I tried so many things, I get lost...

Now I need to understand the delta between libraries...

Is there somewhere a document describing exactly the different packets to send to ITHO for each commands and the order ? I see https://www.progz.nl/homeautomation/2015/05/19/reverse-engineering-remote-itho-cve-eco-rft-part-6/ but this is not clear the exact sequence of messages to send...

Have a good day,

[supersjimmie]

Sorry, that progz.nl blog is the base of all code, and the only place where all packets are extracted and analyzed in detail. The problem is that we have not "cracked" the coding, we only reverse-engineered them in such way that "it works".

You can use a simple tool like notepad++ of even diff to compare the code-parts in incmve library with this library. It sounds like your itho expects other codes, which incmve sends and this library doesn't.