Latest Raspberry Pi OS
MichaelB2018 opened this issue · comments
I'm probably missing the obvious, but hoping somebody just knows the answer. This GPIO control (and therefore the remote commands) work obviosuly fine if I use a Raspberry Pi OS that is about 6 month old (eg. 4.9). But as soon as I build a new SD card with the latest Raspberry Pi OS version (5.4) or as soon as I do a dist upgrade on the old version, the remote stops working. I suspect there is something needed to permission GPIO in the latest version or a difference in connecting to GPIO. But what ever I did so far, I could not get the remote this working on Raspberry Pi OS 5.4
What am I missing?
try checking pigpiod -v
I've got version 71 and it seems to work OK
root@pi4:~# uname -a
Linux pi4 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux
root@pi4:~# pigpiod -v
71
If that doesn't help maybe post your log file and I'll compare
I've got 71 both
Thew one that does not work:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux
pi@raspberrypi:~ $ pigpiod -v
71
The one that works:
pi@somfy:~ $ uname -a
Linux somfy 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
pi@somfy:~ $ pigpiod -v
71
Hi, same here - Pi-Somfy worked perfectly until upgrading from Strech to Buster recently. I reinstalled Pi-Somfy and can't add the shutters when using Buster.
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux
pi@raspberrypi:~ $ pigpiod -v
71
Any ideas? Thank you!
is there any log file available where I could derive information from what could be wrong? Thank you
is there any log file available where I could derive information from what could be wrong? Thank you
/var/log/OperateShutters.log by default I think
2021-04-11 20:22:33,616 : [DEBUG] (Thread-97 ) CONFIG FILE WRITE ->> mySectionStart = 103, mySectionEnd = 104, myLine = 104
2021-04-11 20:22:33,626 : [INFO] (Thread-97 ) Remote : 0x279621 (wz)
2021-04-11 20:22:33,627 : [INFO] (Thread-97 ) Button : 0x02
2021-04-11 20:22:33,627 : [INFO] (Thread-97 ) Rolling code : 2246
2021-04-11 20:22:33,628 : [INFO] (Thread-97 )
2021-04-11 20:22:33,628 : [INFO] (Thread-97 ) Frame : 0xA7 0x20 0x08 0xC6 0x27 0x96 0x21
2021-04-11 20:22:33,628 : [INFO] (Thread-97 ) With cks : 0xA7 0x24 0x08 0xC6 0x27 0x96 0x21
2021-04-11 20:22:33,629 : [INFO] (Thread-97 ) Obfuscated :0xA7 0x83 0x8B 0x4D 0x6A 0xFC 0xDD
2021-04-11 20:22:34,602 : [DEBUG] (Thread-97 ) sendCommand: Lock released
2021-04-11 20:22:34,603 : [ERROR] (Thread-97 ) Error in Process Command: up: can't multiply sequence by non-int of type 'float' : mywebserver.py:84
Does anyone else face that ERROR in the log file?
nope. maybe post your operateShutters.conf
I decided to fallback to Stretch. Blinds work fine again except ´sending the PROGRAM code does not work. The blinds do not BEEP. Anyone else facing that issue? Thx
except ´sending the PROGRAM code does not work. The blinds do not BEEP
Are you sure you use it the way it was intended?
LONG press on the original remote to put the blind into programming mode, then a short simulated press of the virtual remote to register it with the blind.
is there also a way to do it the other way round: Use a simulated (long) press to then program an original remote? Thx
I don't think our code allows it currently (but you can modify it to send a long P).
You probably don't need it, though what are you trying to do?
- Register a new physical remote? You can enter programming mode with the former physical remote
- Register a replacement physical remote and you don't have the original one? Check your blind documentation, there's a procedure to enter programming mode with no remote (it can be a button to press on the motor or something like cutting power for 2 sec, plugging it again for 7, cutting for 2, pluging it back in)
I successfullyed managed to register a blind using the raspberry and then accidentally de-registered the orginal remote for it. Since the raspberry was registered, the remote allowed that action. So now I can control that single blind using raspberry only, which was not my intention. Therefore I was looking for a way sending a "long P". Is there more documentation on the RTS protocol available? If it's really "only" sending the "P" sequence longer, it sounds like a manageable change in the source code.
Power cutting would be an option too, but I'd like to avoid messing around with house electricity too much.
Is there more documentation on the RTS protocol available?
Long press the ‘Prog’ button on a remote that is already registered to the device, until the blinds move shortly up and down. (TODO: how many frames is a long press?) ;)
If anyone else ever faces the same problem: If you set repetition to 16 when sending the PROGRAM code, the blind switches into programming mode. Jippie!
Awesome!
Hi @MichaelB2018 ,
did you end up finding out why the new OS doesn't work?
It could mean new users for this would not be able to get it to work....
Plenty other users got it to work. No idea why for me it was different.... And when it started to work on an older version, I was happy as I didn't have much time to continue to invest into it :)
I might be having the same problem. Pi-Somfy does not send any RF signal after reinstalling it on a fresh Pi install. (I have tested with a RF receiver that the emitter works)
I faced the same problem when running Pi-Somfy on a clean Buster installation and ended up switching back to Stretch, where everything immediately worked again.
I also had a problem registering the Pi-Somfy when switching to Bullseye. I created a new instance with the latest Buster 4.19 kernel release (2020-05-27), but that also didn't work. I then created another new instance with the latest Stretch release (2019-04-08; kernel version 4.14) and this worked. However, around that time I also performed a full reset of the motor, so this might be related. I then moved the Stretch Pi-Somfy configuration to the Bullseye instance, and it worked fine. Finally, I tried to re-register Pi-Somfy from Bullseye, and then both the Stretch and the Bullseye instances stopped working.
I compared the received waveforms from the two instances and they appear to be almost identical (the magenta waveform is Stretch).
The Stretch instance delays the falling edge by 28 μs compared to Bullseye, but I don't think this could be the problem's cause.
My current working hypothesis is that somehow the motor's controller locks up when attempting to add a control with a fresh configuration file.
I finally ended up buying a TaHoma Switch and I am very happy with it.
Resetting the motor controller to factory mode (2" off, 10" on, 2" off, on) and then programming again the limits, allows adding Pi-Somfy as a remote from a Bullseye distribution of Raspberry Pi OS. So it seems that the problem stems from attempting to re-register Pi-Somfy after an upgrade.
The issue still persists.
I tried it with RPi Zero 2 with several versions of Raspberry OS, including the oldest possible for this board (2021-05-07 Buster Lite) and this did not work.
Then I tried my spare RPi Model B+ v1.2 with Raspbian Buster Lite 2020-02-13 and it worked like a charm on first try.
I really love your work and I'm willing to troubleshoot it with later versions, so can you give me any hints?
My conclusion was that the motor controller refuses to serve / locks up / fills up when presented with old / wrong / too many remote codes and sequence values. Have you tried resetting the motor controller? It worked for my with Bullseye.
You can start your troubleshooting by looking at the values sent out in /var/log/operateShutters.log.
For in-depth troubleshooting you can look at the actual waveforms sent out. I used PicoScope for this, but PiScope should also work.