Closed jgaret closed 7 years ago
This way it will not work with the other rfxcom model. I will add some other changes to make it work with both models.
The PR is usefull for me to get the good informations, I will close it when the fix will be ok
I am not sure it's a model problem. I guess it's more related to firmware version. But it needs testing to be sure.
Can you try with the last push on develop ? I didn't check for the 20 length but for the 14 length which was the diff I found in the logs you give me by email.
Why did you use 20 on your side ?
Notice : I will try to get a recent documentation about rfxcom sdk as we are currently doing only some hypothesis
Additionnal information : in a february 2016 SDK, I found that the waited message can be a length of 0x14 or 0x0D I will wait for your feedback before doing new updates.
I also requested the last SDK to Rfxcom.
It works from develop. rfxcom plugin starts and gets the packets.
This is a good news :)
On Sat, Mar 25, 2017 at 11:03 PM, Julien Garet notifications@github.com wrote:
It works from develop. rfxcom plugin starts and gets the packets.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fritz-smh/domogik-plugin-rfxcom/pull/17#issuecomment-289242574, or mute the thread https://github.com/notifications/unsubscribe-auth/AEWKcgMhbFCbdGL3tVpT9QCp8kIkW4IXks5rpY8mgaJpZM4Moud0 .
Integrated with commit https://github.com/fritz-smh/domogik-plugin-rfxcom/commit/b2a23d9926bd0c48b72021bf69f65ddf3c5d4201 I am closing this PR, now useless.
…le démarrage du RFXTRX433E avec firmware plus récent