[VrahoK]

Hi everyone,

I'm using the Quigg GT-1000 protocol with my Brennenstuhl outlet switches. I wanted to use 2 Raspis to improve coverage but actually saw performance decreasing when both were enabled. Using an RF receiver and checking the spectrum I saw something odd: Whenever I switched one of the Brennenstuhl outlets, the transmitter would keep transmitting its tone signal after the sequence was done (no matter which configuration, no matter if "on" or "off" state were switched). I have some other switches I'm talking to using the cogex / archtech_switch_old protocol, this one disables the TX after the sequence is done.

I have taken some time to look into the protocols and understand how the raw codes are generated. I do not yet understand, what these codes actually mean. They are pretty much just an array of numbers and the protocol is just pulses/OOK on the air so I could imagine something like the first number tells you how long the ON pulse shall be, followed by an OFF pulse of the length given by the second number and the 3rd number is again an ON pulse and so on. Could anyone either confirm or point me to the code, where the raw[] values are being applied? If my assumption were true then that might already explain the behavior of the Quigg GT-1000 as the RAW_LENGTH (151) is an odd number which means the pulse train starts with an ON and ends with an ON pulse and may never be switched off. In that case an easy fix might be to put a small OFF pulse at the end just to make sure the transmitter is disabled after the event has gone. Also a general implementation of a final switch off after each event might make sense.

The protocol implementation can be found here: https://github.com/pilight/pilight/blob/...g_gt1000.c

I'll continue digging through the code and trying to understand how the raw[] values are being applied to the transmitter but any quick explanation, confirmation of my assumptions or pointing me towards the right code would probably make this way more efficient.

Thanks!

[curlymo]

You should add an additional pulse after this line in the same array:
https://github.com/pilight/pilight/blob/...000.c#L269

However, not sure if that breaks the protocol.

[VrahoK]

Some progress: I found https://github.com/pilight/pilight/blob/...33gpio.lua taking care of the actual sending of the code. Looks like the "digital_write" has been overloaded by the "plua_wiringx_digital_write" to accept also 3 args containing a list of timings. And it actually looks like my assumption is confirmed, that the list of raw pulses is the alternating lengths of on and off pulses.

Now a potential issue (to be confirmed): There actually is a section inside the function M.send(timer) that is supposed to take care of setting the GPIO to LOW at the end but I think the condition is wrong as we always start the transmission chain with a HIGH signal so in case the count is ODD it should write an extra 0 to the sender PIN. The current implementation is checking for an EVEN number of pulses (which doesn't hurt as the PIN is already LOW and will just be set to LOW again):

Code:

            --
            -- Make sure we don't leave the GPIO dangling
            -- in HIGH position.
            --
            if (count % 2) == 0 then
                wx.digitalWrite(sender, 0);
            end

Btw: I'm not sure about the potential performance impact but would it hurt a lot to just set the GPIO to LOW after each transmission unconditionally?

[curlymo]

The hardware module is written in lua so you can easily check if your suggested fixes work.

[VrahoK]

I have manually changed the 433gpio.lua file and can confirm that changing line 50 from

Code:

            if (count % 2) == 0 then

to

Code:

            if (count % 2) ~= 0 then

fixes the issue. I have verified that the transmitter is now shut off after transmitting for the Quigg GT-1000 protocol (ODD number of pulses) and is still working correctly for the cogex protocol. I have no other HW to check if I didn't break anything else. Please let me know if more verification is required before merging this fix. Would you like me to set up a PR or is that straighforward enough to be done from your end directly?

[curlymo]

And what about your suggestion to remove the condition alltogether?

[VrahoK]

And what about your suggestion to remove the condition alltogether?

Sorry, I already created a PR and just now read your response. Unfortunately I have no experience how wasteful an extra call / GPIO write is for the RPi and I have no means of testing the potential performance degradation caused by that (which is probably neglectable but anyway). This is obviously a safety vs. performance question.

I'd personally lean towards the safe way here and disabling the sender no matter what, as otherwise you might create interference which not only blocks your relays from working correctly but may also interfere with your neighbors installation etc (and it may actually break local laws regarding RF transmission...).

I have tested removing the condition completely and the result is the same as above. If you don't see any risk in that, I can also adapt the PR to remove the condition altogether.

[curlymo]

The idea is to make sure the sender is left in an off state after sending. Two subsequent off's aren't going to do anything usefull except the duration of the off is increased. But because it's the last transmission that doesn't matter much. So let's remove the condition altogether.

[VrahoK]

The idea is to make sure the sender is left in an off state after sending. Two subsequent off's aren't going to do anything usefull except the duration of the off is increased. But because it's the last transmission that doesn't matter much. So let's remove the condition altogether.

Agreed, the actual lenght of the last OFF pulse of the sequence is only required to ensure enough gap between repetitions of a sequence. For the last OFF it doesn't matter if it is switched OFF again.

I have adapted the PR.

[VrahoK]

One minor question: Is there a way to figure out which commit the nightlies correspond to? Looks like the latest one from tonight doesn't have this fix in yet.

Thanks!