Nickduino/Pi-Somfy

32 to 64 bit issue

Closed this issue · 11 comments

Hi,

Pulling my hair out with a strange problem, setup pi-somfy with a single rts blind a couple of years ago, worked flawlessly no issues, and this was running the pi-somfy in a container on my Home Assistant Pi4 host. For other needs, I have rebuilt my Pi4 HA host in 64 bit OS, and now pi-somfy is broke. The container runs, web ui works, if I run 'pigs csi 5' and 'cat /dev/pigerr' I can see all the commands to the gpio (not sure if this is definitive its all working?). So assumed it is a 64 bit thing, rebuilt an old pi in 32 bit rasbian buster, built current version of pi-somfy from scratch, same issue no response from blind. Ran the original container, again nothing, but still seeing commands through /dev/pigerr. Assumed co-incidentally I had broken the hardware, so built another board from scratch, and again nothing. Any pointers where to look? Blind responds fine from remote, and have completely reprogrammed, still doesnt work with Pi-Somfy. My suspicion is that the board is not emitting anything on 433Mhz, is there any easy way with "standard stuff in the house" I can prove anything is being broadcast by the pi, or is that the realm of specialist equipment? Thanks for all your work on Pi-somfy

If you have an arduino, you can use the sketch to check reception: https://github.com/Nickduino/Somfy_Remote
Put the arduino the near the Pi, this will provide you a clue if it is a range issue

Thanks for the response. I think I have some spare bits about to build that, assume the little crystal h/w board can operate as a receiver as well as transmitter?

I have been continuing to work on the pi and have discovered that if I run the original container, add a new cover, the blind doesn't jog, but if I press the button on the remote (as per the instructions) the blind jogs, then if I try again in the web UI again, the blind jogs again, so I assume this means the h/w is working as the blind reacted? I then click "It worked" and it hangs, throwing an "Error in Process Command: getConfig: 'durationDown' : mywebserver.py" in the logs.

If I run this newly installed on the same h/w (no containers) the blind doesn't respond, and I have checked the pigpiod and operateShutters.py are identical. So struggling to work out why the blind at least responds with a "jog" from the container but not from directly

Perhaps I have got the blind in a mess and need to factory reset, is that possible?

Thanks for the response. I think I have some spare bits about to build that, assume the little crystal h/w board can operate as a receiver as well as transmitter?

I believe @kenji21 suggestion was to test the hardware emitter by connecting it to an Arduino (to use it as a virtual remote for the shutters, not a receiver) because my sketch can't receive commands (and, more importantly, wouldn't tell you if they're sent to the precise frequency).

I have been continuing to work on the pi and have discovered that if I run the original container, add a new cover, the blind doesn't jog, but if I press the button on the remote (as per the instructions) the blind jogs, then if I try again in the web UI again, the blind jogs again, so I assume this means the h/w is working as the blind reacted?

Yeah, you have to enter programming mode with the original remote (long press on the P button) and then register the new (virtual) remote by pressing the P button on that one. It appears that's what you've done (or possibly did the opposite if that same virtual remote was previously registered with the blind).

I then click "It worked" and it hangs, throwing an "Error in Process Command: getConfig: 'durationDown' : mywebserver.py" in the logs.

But you have access to the GUI with the three buttons? The blind doesn't respond when you click either?
To test the stop button, you'll have to make the blind move first with the original remote.

Perhaps I have got the blind in a mess and need to factory reset, is that possible?

The Python script wouldn't throw an error because you "have got the blind in a mess", it wouldn't know it.

my suggestion was to get a receiver (which can validate reception using the real remote)
https://www.hackster.io/frankbeen/somfy-rts-receiver-295382 (or maybe using this lib: https://reference.arduino.cc/reference/en/libraries/somfy_rts/), mine was using an old forum post (from 2012... didn't found it back)
and then you can test that your virtual remote is working ^^

my suggestion was to get a receiver (which can validate reception using the real remote) https://www.hackster.io/frankbeen/somfy-rts-receiver-295382

Ok but you won't know your transmitter is actually transmitting to 433.42 MHz

(or maybe using this lib: https://reference.arduino.cc/reference/en/libraries/somfy_rts/), mine was using an old forum post (from 2012... didn't found it back) and then you can test that your virtual remote is working ^^

No, he just copy/pasted my code (for a transmitter, it won't receive)

I found the thread (which has been moved to a discourse) : https://forum.arduino.cc/t/protocole-somfy-reverse-engi-rts/202983/63
Here are the sketch/code for both transmission and reception
But you're right, it won't let you know if you're emitting at the right frequency, but it would make you able to determine if it send something or nothing (hardware issue then ?)
Does the 64 vs 32 can affect the pigpio timgins, like here: #136 (comment)

it won't let you know if you're emitting at the right frequency, but it would make you able to determine if it send something or nothing (hardware issue then ?)

I wonder if this reception sketch is sensitive to timing.

I agree @alastaid should do the test I mention here: #136 (comment)

Hi all, firstly thanks again for the replies, much appreciated. I have continued to investigate and have made some progress, not that it makes much sense to me at the moment. I have switched to 32bit for the moment, and have rebuilt a new pi, with a new transmitter, and from that the only thing I could get to work, was running the old container and adding a new blind, when I pressed the button on the back of the blind remote after the blind jogged, I could hit the try again in the UI and the blind would jog again, so I knew the h/w was working to some degree, the UI would hang after hitting "It worked". So I then reset the blind back to factory defaults, and could successfully add the blind and can control it, with both the old transmitter board and the new one running directly on the pi. So essentially I have gone round in a huge circle to get back to where I was before I upgraded my HA host to 64 bit, it looks like resetting the blind to factory was the key. I am now going to try and build a container, either 64 or 32 bit to see if I can get it working back on the HA 64 bit host and will report back for interest to others, and then we can close this. Thanks again for the support.

Nice to see you progress.
If it doesn't work with your new 64 bits install, do the PiGPIO timing test.

So spent a good while with the 64 bit host, and whilst I could get this to run occasionally, either with a 64bit or 32bit container, it was never reliable, and I just couldn't pin it down. Bizarrely it even worked once with the pigpiod -t 0 option and then without after. When running, it would be perfect, but then on reboot, or restart of container it wouldnt, and I would fiddle again and may or may not get it working, no error messages in the logs. Hence I have thrown the towel in, and dug up an old Pi 1, built it on there and it works perfectly straight off the bat. Maybe when I have more time I will revisit, but for now please close this off and thanks for support.

There's no shame in going for the pragmatic solution sometimes, even if it feels like a defeat.