conflict between nexus and tfa protocols?

[mihai-catalin]

Hi, I discovered this with OMG and before addressing it to pilight I raised it here maybe someone has an idea. I have a DG-R8S which in Pilight v0.16.2 is decoded as TFA, but not decoded in Pilight v0.17.0. I have a DG-R8H which started with Pilight v0.17.0 is decoded as NEXUS. Using Pilight v0.17.0 I did following tests:

• delete NEXUS but keep TFA -> DG-R8S started to work, but DG-R8H doesn't work (normally as it is nexus)
• delete TFA but adding back NEXUS -> DG-R8S stopped to work and DG-R8H started to work
• both NEXUS and TFA are present -> only DG-R8H is working

In other words, seems when both protocols are present NEXUS has priority over TFA. I tried to figure myself if here is a prioritization mechanism but with my limited knowledge I could find something. Does anyone has any idea what could be? Thanks

[NorthernMan54]

And I also found that my "alecto_ws1700" sensor stopped working once nexus was added. After delving into the code found that the mingaplen from the nexus protocol is 3600 and is triggering the issue.

[mihai-catalin]

And I also found that my "alecto_ws1700" sensor stopped working once nexus was added. After delving into the code found that the mingaplen from the nexus protocol is 3600 and is triggering the issue.

Thanks! Did you change it and test after? I will have a look myself later this week.

[NorthernMan54]

To resolve my issue, I had commented out the nexus protocol. If I had a nexus device I may have attempted a fix, but unfortunately I don’t have one.

[mihai-catalin]

To resolve my issue, I had commented out the nexus protocol. If I had a nexus device I may have attempted a fix, but unfortunately I don’t have one.

Finally, I was looking into this but didn't find a way to move forward. I have devices from TFA, NEXUS and ARCTECH_SCREEN_OLD and comparing the mingaplen I found the one from nexus is very small comparing with the others. Can you give me a hint how I should change this parameter (what values) to accommodate more protocols? Thanks

[NorthernMan54]

For me to make a recommendation I would need access to all your devices and then do regresssion testing to determine the right value.

You could just increase the value in the nexus code and see what happens.

On Feb 20, 2021, at 3:25 PM, Catalin [email protected] wrote:

 To resolve my issue, I had commented out the nexus protocol. If I had a nexus device I may have attempted a fix, but unfortunately I don’t have one.

Finally, I was looking into this but didn't find a way to move forward. I have devices from TFA, NEXUS and ARCTECH_SCREEN_OLD and comparing the mingaplen I found the one from nexus is very small comparing with the others. Can you give me a hint how I should change this parameter (what values) to accommodate more protocols? Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[hannemann]

@mihai-catalin any progress on this? Did you try to increase the value in the nexus protocol?

I also own a tfa device and commented out the nexus protocol for now

[mihai-catalin]

@mihai-catalin any progress on this? Did you try to increase the value in the nexus protocol?

I also own a tfa device and commented out the nexus protocol for now

sorry for late reply. I tried to find theoretical values to cover all my devices and didn't find them. BTW, it is strange the nexus is working together with arctech_screen_old because normally should be a similar conflict as between nexus and tfa. In consequence, I drop this path and focused on rtl_433 (all my devices are working with this); now I'm waiting the RF module to do it with ESP32. I not very happy I will throw away the RF bridge which is a very nice device.

[ligius-]

Sorry, the minGapLength was triggered by me, otherwise the nexus decoder that I wrote would not work. See here the details but cannot really remember everything right now. If I had a TFA sensor I could play around.