HAB Community, Hi there !
When executing a group command, to differents peripherals using different RF protocols, it appears that the transmission may fail , it these protocols send on the same frequency at the same time.
Can a general mechanism be implemented, to solve this issue ( a kind of delaying mechanism )
Thank you for ideas !!
Not really. Proper retransmission handling needs to take place at the radio layer, anything like an application level retransmission mechanism could lead to serious instabilities and problems of the ‘hard to find’ sort.
I strongly advise against it (and being a Telecoms engineer, I have encountered many situations similar to this and know what I’m talking about …).
Many radio protocols such as ZWave and ZigBee do implement retransmissions already at the radio layer, and with another retransmission layer at the application level, they would continue doing so.
In short: you would just create more traffic jam.
Sorry to tell you (you likely don’t want to hear about that), but the best solution for you would be to get rid of your zoo of systems/protocols that share the same frequency. Consolidate to a single radio system, preferrably one to have retransmission and routing built into the radio layer (because in total, it is using the RF spectrum more efficiently than those systems without these capabilities).
I know the situation, I do encounter it at times, too (I have ZWave and MAX! collide).
Just like the best solution to cope with traffic jams is to just drive when the others don’t, my workaround is to introduce artificial delays (using Thread::sleep()) in the loop that goes through the group members.
It’s working, but I still keep getting drop messages at times - they are a constant warning that I should never ever buy another system to use this radio band, even if it seems to be way cheaper - in the long run, it isn’t.
Typically, protocols should use a random backoff when retrying - ie not always use a certain fixed time to resend a transmission, but to add some randomness to the retransmissions so that retries don’t become syncronised. This is really about all that can be done, and most systems should do this.
In theory (ie by law!), all systems using the unregulated ISM bands are required to accept interference from other services that also use the bands. Additionally, they are required to only transmit for a certain percentage of the time so that other services have time to interoperate. However, while I suspect that system like ZigBee and ZWave will at least attempt to comply with this, less regulated, home built systems probably ignore it.
I would argue that if you are using multiple systems, then you need to think about this sort of thing as you are effectively the system integrator. If you only have a single system, then things will likely work ok, but the more systems you have in the same band, you will start to experience issues, and you will need to consider the interoperability issues. So, as @mstormi said - try to consolidate your systems and avoid using systems that will conflict if at all possible.
Another point to remember: while the ISM band is free of licensing, it’s not totally unregulated. Devices are required to occupy at most 1% of the bandwidth (by law in Germany, but I assume it’s EU or world wide), and while there might be some devices to ignore that, you can’t sell products to not follow the law, so in fact more or less every vendor is implementing this. Note that this also applies to the controllers.
With that in mind, it’s rather unlikely to have transmissions clashing.
For group type of commands (many single commands in a short period, effectively), this can result in a large sender queue and might trigger timeouts. It depends on the implementation of the 1% rule, of course (you can send for a whole minute if you stay quiet for the next 99). But you might not be seeing transmission clashes but timeouts in fact, with a misinterpreting piece of software somewhere in the stack to not properly output that as the true reason.
Either way, your best choice is to consolidate.