Raspberry 3B+, RF Light On, Light Off, Dim Light

[admin]

Reverse enginering TR-502MSV remote control sender.
Same as Brennenstuhl HS 433.



PCB: TR502A3
Left (white) one is defect, but wana try to control receivers (3 + 1 dimmer) with RPi.

The sender has a MCU kinda blob on its PCB and a second smaller PCB with the transmitter.
So we have no idea which ic-chip is used for this rf-system.
It has a 433MHz oscilator, so this should be possible to re-create.
Button part of sender has 455kHz ceramic oscilator (code) and passes it to 433MHz transmitter.

We made our own halogene remote as exam project 30 years ago, IR-led driven, 455kHz, with Pulse Pause Modulation (PPM), we also want to implement this into new (raspberry) remote?
We'll see if we can arrange that later on.

Received the Raspberry/Arduino 433MHz transmitter and receivers.



Also new remote control (Brennestuhl HS 433) for broken sender with even more receivers and dimmers.

We tested all outlet-receivers with the new remote control and working fine.
The new rpi-receiver does work. We see data on scope.
But the raspberry does not recieve any usable data, it's always something else? (noise?)
We tried: RFSniffer, rfscanner?, rpi-rf_receiver & send, but all return no usable data.
Should I use a voltage divider?

Yes, with rfrecorder I've (rf)recorded 1 switch 'on' function, the 'off' still did not work.
We have to analyze the recorded data.
Also for switch1 we found the 'on' data, not the 'off' data...



This is from rpi-rftransmitter, which also include rfscanner.
But with too much noise, rfscanner printing rubbish on screen.
Rewrite in python will be best sollution, i guess.
rfrecorder does check receiver data for 5 times before saving into file.
With this command (and a small voltage divider) I received the 'on' function for SW1 and SW2.
Not (yet) the 'off' functions...

Some code testing....

RFSW2ON: 20230116235953.rfdat

Code: Select all

-----_______------------______------------______------------______------------______------------______------------______------------
580  660    1270        645   1270        650   1265        650   1265        665   1265        650   1265        650   1265


______------------______------------______------------______------------______------------____________------______------------______
650   1265        670   1260        655   1260        655   1260        650   1265        1340        590   655   1235        655



------------____________------______------------______------------____________------____________------____________
1220        1300        590   665   1235        660   1220        1300        590   1300        595   73685 

times in usecs

Total is about 112,5 msec, without the last 'off' command (74685usec) it is: 39 msecs

60 bits in 40msec makes about 666 usecs/bit.
We dont want double byte be longer than 1300 usec, so we take 650 as base clock. (Triple bits do NOT exist!)

Now testing own made code:

RFSW1ON
1011 0110 1101 1011 0110 1101 1011 0110 1101 1011 0110 1100 1011 0110 1100 1000

RFSW2ON
1011 0110 1101 1011 0110 1101 1011 0110 1101 1001 0110 1100 1011 0110 0100 1000

Using 650 as base usec for data, 1300 as double bit ...
This is working fine!

Guessing RFSW3ON ?

Code: Select all

RFSW1ON =
1011 0110 1101 1011 0110 1101 1011 0110 1101 1011 0110 1100 1011 0110 1100 1000
RFSW2ON =
1011 0110 1101 1011 0110 1101 1011 0110 1101 1001 0110 1100 1011 0110 0100 1000
<-----         this is all the same ...   --->
                                              <--  contains lamp & func. -->
RFSW3ON = 
1011 0110 1101 1011 0110 1101 1011 0110 1101 1010 0110 1100 1011 0110 1010 1000

And guess what? (TF?) It works!

With piscope:

RFSW1ON


RFSW2ON


RFSW3ON

(Not all are set to right '0'-left-position.)

We now will find the 'off' function!

Searching first for SW 4 we found (typically) the OFF function of SW 1, funny.

Code: Select all

RFSW4ON ?
1011 0110 1101 1011 0110 1101 1011 0110 1101 ???? 0110 1100 1011 01?? ??00 1000
                                             1011 0110 1101 1011 0110 1100 1000  ???   !!! +++ === SW1OFF , LOL
                                             0010
                                             0101
                                             0110   <---              xxxx       also fits here ;)
1011 0110 1101 1011 0110 1101 1011 0110 1101 0110 0110 1100 1011 0110 0110 1000
but, It's a NO. (for now, 3 times 2 bits @ end.)

                                             0011   <---                         2nd choice ?
RFSW4ON ?  2nd guess
1011 0110 1101 1011 0110 1101 1011 0110 1101 0011 0110 110x 1011 0100 1100 1000
1011 0110 1101 1011 0110 1101 1011 0110 1101 1001 0110 1100 1011 0110 0100 1000
And this is SW2 again?  weird ...

Clearly '10' is the start sequence (or more, but if we stay with that...), we see a '110' pattern.
What if we just sent this 3 bits untill the end?
There we found the OFF for SW 1 !

From here we wont divide into 4 but 3 bits.

Code: Select all

Yes we did! 
And we found more: after start (10) always 3 bits (110) and always switch after 2 same bits.
stop = 01

Manual says 4096 different codes (with the reset button) which most probably will change the first 12 bits.
(see below)

example
In this example are no 3 bits the same after each other (serial transmit protocol).
So the receiver can determine the clock out of the data.
All changes for lamp and function are so, that still no 3 bits, or 3 times (set of) 1 or 2 same bits after eachother do not exist.
(end of SW 3, there is an error?)

10 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 01  this code switches lamp 1 OFF
st  0   0   0   0   0   0   0   0   0   0   0   0 | 0   0   0   0   0   0   0  sp  start bits (per 3) stop
   <--  most probably the remote control code  -->
                                                   <--  lamp/function code -->
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 010 110 110 110 01  lamp 1 ON
                                                               *                   * => 0=ON, 1=OFF

01 110 110 110 110 110 110 110 110 110 110 110 110 010 110 110 010 110 110 010 01  lamp 2 ON
                                                   0           1           0       lamp 2 OFF

01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 010 110 010 010 01  lamp 3 ON   ???
                                                               1       0   0       lamp 3 OFF  ???
Have to check with real data ..... jan 2023


SW1
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 010 110 110 110 01 ON
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 01 OFF

SW2
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 010 110 010 010 01 ON
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 010 010 01 OFF

SW3
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 010 110 110 110 01
01 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 01

Seems not fully correct.

1 day later ...

Still not exact the right code (or timing sequence) As we now only struggle with SW 4
SW1, SW2 and SW3 are remote on/off outlets wich now can be controlled by a raspberry (or remote control).

We have to set 1 bit other then SW1, SW2 and SW3, according ON/OFF function.

Our 'selfmade' code is 39 msec long, the 'real' data about 38 msec, but it could be a culprit.
We'll see. My code uses 650 and 1300 usecs for timing the data.
Could be a little less to get to 38msec for full 61 bits.

For now we can do ON/OFF as on the remote for 4 outlet-switches.
We did record all RF data of the OFF switches, with rfrecorder.
Start sending before start recording helps to get the right code. Especially with bad receivers!

Next the dimmer function, which is in SW4. Bright & Dim.
...

Found and used some of the following links:

https://www.electroschematics.com/433mhz-rf-sniffer/
https://www.electroschematics.com/rf-re ... -teardown/
https://www.wellpcb.com/433MHz.html
https://dserv01.home.blog/howtos/funkst ... t-arduino/
https://www.clasohlson.com/medias/sys_m ... 147422.pdf
https://www.tektouch.net/devices/remote ... ockets.php
http://www.fhemwiki.de/wiki/Hauptseite
http://www.fhemwiki.de/wiki/SIGNALduino ... BCber_HTTP
https://fetzerch.github.io/2014/11/15/reveng433/
https://github.com/Portisch/RF-Bridge-EFM8BB1/issues/58

https://www.instructables.com/Super-Sim ... utomation/
https://tutorials-raspberrypi.com/let-r ... s-signals/
https://tutorials-raspberrypi.com/contr ... -tutorial/
https://pypi.org/project/rpi-rf/
https://pagealh.wordpress.com/2015/04/2 ... -txrx-kit/
http://jap.hu/electronic/rf.html

https://www.stavros.io/posts/how-remote ... pberry-pi/

https://ralf9.github.io/SD_Device_Proto.html
with table:

Code: Select all

dev	ID	MsgType	modulname	protocolname					# comment
	34	MU	SD_UT		QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC	remote control DMV-7000, TR-502MSV, 58608

Message type = MU
Module name = SD_UT

DG.

[admin]

Founded data which is changed with the remote are within the bits 39 to 61.
The first 38 bits never change, most probably if you change the 'basic' code (reset within battery compartment).

Code: Select all

bit 1                                               38
    |                                                |
    01 110 110 110 110 110 110 110 110 110 110 110 110

For the 1 - 4 ON/OFF switches:

Code: Select all

bit 39                           61
     |                            |
SW1  110 110 110 *10 110 110 110 01
SW2  010 110 110 *10 110 110 010 01
SW3  110 010 110 *10 110 110 110 01
SW4  010 010 110 *10 110 110 010 11   <- Last 2 bits, weird one, must be 01 for OFF
     +   +       |           +
                 Lamp 0=ON, 1=OFF
+ = bits that change with SW buttons

For the brightness and dimmer function:

Code: Select all

bit 39                           61
     |                            |
Bght 110 010 110 110 010 110 010 01
DIM  110 010 110 010 010 110 010 11
                 +   0           +
+ = bits that change with bright and dim buttons, and bit 62 = 0

For now we used 650 and 1300usecs for own made code, perhaps this should be a little smaller (620, 1240?).
Have to test that.

DG.

[admin]

Made the following overview of data:



DG.

[admin]

And yes, also our (back)doorbell can be recordered and played back.

Code: Select all

Done! Sample:
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 765 usec, OFF for 260 usec
>>> ON for 245 usec, OFF for 790 usec
>>> ON for 760 usec, OFF for 270 usec
>>> ON for 760 usec, OFF for 270 usec
>>> ON for 765 usec, OFF for 260 usec
>>> ON for 245 usec, OFF for 790 usec
>>> ON for 760 usec, OFF for 270 usec
>>> ON for 755 usec, OFF for 270 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 765 usec, OFF for 270 usec
>>> ON for 760 usec, OFF for 270 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 765 usec, OFF for 260 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 245 usec, OFF for 790 usec
>>> ON for 760 usec, OFF for 270 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 765 usec, OFF for 270 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 245 usec, OFF for 780 usec
>>> ON for 245 usec, OFF for 8275 usec

Sample has a score of 100.00%.Saved to 20230124121643.rfdat!

Although we changed it here a bit otherwise everybody can 'ring my bell' .

25 pulses (=24bits) in 25,2 msecs.
About 333 usecs per pulse.

serial stream:
1001101001101101101001101101001101101001101001001101001001001101001001001

Makes data:
010111011011010010001000

DG.

[admin]

Useful link for remote command execution:
https://www.digitalocean.com/community/ ... nux-server

DG.

[admin]

Fully working 3 light on/off, 1 dimmer and 1 doorbell working from RPi.

The RF sender/transmitter for the Rpi is moved to the RPi4, which also do Internet on TV (youtube, movies, internet, etc).
A new 'remuser' was needed on the RPi4, as described in the link above.
This for the web-server to perform DG-Light action(s) on the RPi.

More lights to be added, we have some receivers but they will not be able to be controlled by remote, only by app on web-server.
The RF related stuff will be posted here, as the system can be connected to any RPi.

DG.

[admin]

As we use(d) rpi-rftransmitter program, which is build on wiringPi package.
But the website of wiringPi is no longer available:


Should we make/use a new program to send/receive RF data? Or do we stay on the old version?
(https://www.instructables.com/RF-433-MHZ-Raspberry-Pi/)
For now we try stay on old version, although we do need newer code also for the new garage-door.

WiringPi is still available from github: https://github.com/WiringPi
Rpi-rftransmitter also on github: https://github.com/ikkentim/rpi-rftransmitter

And I found out that on new Raspbian 12, WiringPi can NOT be installed:
First the file needed to be of user: _apt, and not in a user directory (put it into /tmp).

Code: Select all

-rw-r--r--  1 _apt   dguser 58840 Feb 12 13:35 wiringpi-2.61-1-arm64.deb

From other locations we get an error during install, as user _apt may not use /home/ directory:

Code: Select all

$ sudo apt reinstall ./wiringpi-2.61-1-arm64.deb 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'wiringpi' instead of './wiringpi-2.61-1-arm64.deb'
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/58.8 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /home/dguser/wiringpi-2.61-1-arm64.deb wiringpi arm64 2.61 [58.8 kB]
(Reading database ... 242815 files and directories currently installed.)
Preparing to unpack .../wiringpi-2.61-1-arm64.deb ...
Unpacking wiringpi (2.61) over (2.61) ...
Setting up wiringpi (2.61) ...
/bin/chown: warning: '.' should be ':': ‘root.root’
Processing triggers for man-db (2.11.2-2) ...
N: Download is performed unsandboxed as root as file '/home/dguser/wiringpi-2.61-1-arm64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

From /tmp the install goes ok:

Code: Select all

$ sudo apt reinstall ./wiringpi-2.61-1-arm64.deb 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'wiringpi' instead of './wiringpi-2.61-1-arm64.deb'
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/58.8 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /tmp/wiringpi-2.61-1-arm64.deb wiringpi arm64 2.61 [58.8 kB]
(Reading database ... 242815 files and directories currently installed.)
Preparing to unpack /tmp/wiringpi-2.61-1-arm64.deb ...
Unpacking wiringpi (2.61) over (2.61) ...
Setting up wiringpi (2.61) ...
/bin/chown: warning: '.' should be ':': ‘root.root’
Processing triggers for man-db (2.11.2-2) ...

But running 'gpio readall' returns an error, which was not on older versions of Rpi OS:

Code: Select all

$ gpio readall
Oops: Unable to determine board revision from /proc/cpuinfo
 -> No "Hardware" line
 ->  You'd best google the error to find out why.

The raspberryPi website has an answer:
https://forums.raspberrypi.com/viewtopic.php?t=362293

Code: Select all

the hardware line was removed, and wiringpi was deprecated years ago
you need to switch to another gpio library

So we DO need newer code to perform my old actions...
Have to investigate how.

Build new, bases on: https://www.instructables.com/Super-Sim ... utomation/ ?

DG.

[admin]

As of Debian bookworm, we need to run python scripts within its own container/environment, as wriiten on:
https://www.raspberrypi.com/documentati ... spberry-pi

Start of the environment: source env./bin/activate
Stop the environment: deactivate

To make new RF code we will be doing this with python, as this is the most common way on RPi's.
But for package: rpi-rf this must be done in venv, a virtual environment for python.

My nicely build -metal cigar-box- receiver seems to be more noizy than other receiver(s).
Now testing one other, which seems to record better results.
Working on this and re-read above, I see:
This must be due to bad receivers, as -back then- the remote must be within 10 cm of it to receive the data above.
For now have only 1 nice pi-scope-screenshot of new -to be used- data? Euh, not yet...

I wanna write python program, based on primary data that will be converted into AM-DATA according Manchester-coding.
Data in: pulse-width, nr of bits, value(s).
Value(s) for the RF-switches: can be made with 0-4096 remote-code (in binary), and 256 data-code (in binary).
Value(s) for doorbell: 0-16777216 (24bits) data

As the Switch On/Off are 20 bits, my doorbell is 24 bits.
I had all codes from remote, but after changing the 'basic-code' of the remote once, I now have new 'base-code' which has changed from the old one.

Found one solution for the noisy receiver on Rpi, as on my scope the signal is not noisy:

youtu.be/vuGWBm2rWmA

We now will try external power supply instead of Rpi power, although 3A should be more than enough for Rpi and peripherals.
Rpi only powers Doorbell receiver (30mA max), RF 433MHz sender (40mA max) mostly not used and the RF 433MHz receiver (15mA max).
That makes not more then 100mA total.

Also tested will be the extra 7805 as mentioned in the video above, after the 5V of the raspberry, only for the receiver, as the sender works perfectly through whole house, 3 floors.

We are getting there ...
Using a separate power supply for the receiver makes a WORLD difference.
Now the Rpi is receiving code from remote, even in next room. This was always only within cm's of the receiver
With lots of noise, and that's all gone now! With a new base-code on remote control, we can add 4 receivers.

Also found next link:
https://github.com/breisa/433mhz
A rather new program to record & send data from and to 433MHz sender & receiver.

DG.

[admin]

With the new code from https://github.com/breisa/433mhz

RF Switches:

We found for SW1ON the following data:

Code: Select all

[[0, 461], [1, 1216], [0, 1309], [1, 585], [0, 110895], [1, 590], [0, 1340], [1, 605], [0, 640], [1, 1255], [0, 1340], 
[1, 591], [0, 655], [1, 1274], [0, 1346], [1, 594], [0, 660], [1, 1260], [0, 656], [1, 1269], [0, 656], [1, 1265], 
[0, 1340], [1, 599], [0, 652], [1, 1254], [0, 1335], [1, 589], [0, 656], [1, 1274], [0, 661], [1, 1256], [0, 659], 
[1, 1229], [0, 655], [1, 1225], [0, 1306], [1, 594], [0, 670], [1, 1245], [0, 656], [1, 1249], [0, 645], [1, 1230], 
[0, 1300], [1, 595], [0, 73675], [1, 585], [0, 1335], [1, 595], [0, 656], [1, 1244], [0, 1340], [1, 596], [0, 655], 
[1, 1269], [0, 1346], [1, 600], [0, 655], [1, 1265], [0, 654], [1, 1261], [0, 659], [1, 1270], [0, 1335], [1, 595], 
[0, 655], [1, 1250], [0, 1350], [1, 586], [0, 1394]]

And for SW1OFF:

Code: Select all

[[0, 36835], [1, 580], [0, 1340], [1, 605], [0, 645], [1, 1260], [0, 1330], [1, 597], [0, 658], [1, 1261], [0, 1349], 
[1, 600], [0, 655], [1, 1265], [0, 650], [1, 1275], [0, 650], [1, 1265], [0, 1340], [1, 595], [0, 655], [1, 1250], 
[0, 1345], [1, 590], [0, 655], [1, 1265], [0, 675], [1, 1255], [0, 655], [1, 1265], [0, 660], [1, 1265], [0, 660], 
[1, 1255], [0, 675], [1, 1255], [0, 670], [1, 1255], [0, 665], [1, 1255], [0, 665], [1, 1260], [0, 63355], [1, 30], 
[0, 47485], [1, 605], [0, 1315], [1, 600], [0, 650], [1, 1257], [0, 1338], [1, 600], [0, 645], [1, 1270], [0, 1350], 
[1, 595], [0, 650], [1, 1270], [0, 660], [1, 1260], [0, 655], [1, 1270], [0, 1335], [1, 605], [0, 645], [1, 1260], 
[0, 1330], [1, 600], [0, 660], [1, 1255], [0, 670], [1, 1260], [0, 660], [1, 1265], [0, 665], [1, 1255], [0, 660], 
[1, 1265], [0, 670], [1, 1255], [0, 660], [1, 1265], [0, 660], [1, 1260], [0, 660], [1, 1260], [0, 24407]]

And this is actually what I was looking for!
This 'data' can nicely be 'read'.
So we also can make our own data from it (cleaned up).

short = between 580 - 675 (avg 628)
log = between 1225 - 1340 (avg 1283)
pause = between 47485 - 110895 (avg 79190)

Using these values and twice sending the 'code' gives for SW1ON:

SW1ON_001.data

Code: Select all

[[1, 628], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], 
[1, 628], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 79190], [1, 628], [0, 1283], 
[1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], 
[1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 79190]]

And for SW1OFF:

SW1OFF_001.data

Code: Select all

[[1, 628], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], 
[1, 628], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 79190], [1, 628], [0, 1283], 
[1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], [1, 1283], [0, 1283], [1, 628], [0, 628], 
[1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], 
[0, 628], [1, 1283], [0, 628], [1, 1283], [0, 628], [1, 1283], [0, 79190]]

And we test this ...
Works like a charm
We see the code is different than before, as we have changed the base-code on the remote control.
Next we cleanup the other codes...

Dual code made the following -clean- 20 bits data:
SW1ON / OFF
SW2ON / OFF
SW3ON / OFF
SW4ON / OFF
SW4bright
SW4dim
SW5ON / OFF
All ON / OFF

Doorbell:

The doorbell did work fine with rftransmitter, but the same code does not work with rfsr433.py?
We having more trouble getting the doorbell 'ring' then getting the RF switches working.
Even with recorded code, the bell is not always ring.
Adjusting the code by u-secs has no effect. We have 1 code that does work, and we now sending it 16 times.
Most of the time this works.

Additional switches:
As for some receivers we do not have a remote-control, this will become more difficult, although we have 1 code to switch one ON, but not OFF.
Additional switched from the same branch (with remote) we can add. (SW5)

All working fine, and also by website...

Todo:
- Gate-code
- some main lights? (Some have hotel-circuit)
- Timing for switches? (ON / OFF on specific times)

DG.

[admin]

And on my Robot-Pi ... the Wifi is -spontaneously- not working anymore?
Raspberry Pi's hardware is not that 'good' after all. It was working fine for some months ago, and now it won't start anymore: missing wlan0.
Have done nothing special. Another Rpi3, which does Flightradar24 did not have this issue and is up-to-date, always networking on WiFi.
I tried only updating this Rpi (on cable) without any issues, but still no WiFi.
Reading the Internet about this issue, it seems that more people have this issues, some have the WiFi complete dead, like mine.

https://forums.raspberrypi.com/viewtopi ... b&start=25
https://forums.raspberrypi.com/viewtopic.php?t=239009
https://forums.raspberrypi.com/viewtopi ... 2&start=25

No erros in dmesg, no mmc1 mentioned, no returns on command like rfkill, iw <something>, or any other seen command
Even Raspberry own tool: raspi-config does not see wlan0.
Enabling it in /boot/config.txt does also nothing.

Stupid Raspberries, always something. Dist-upgrades from ssh, always use 'y' otherwise your upgrade will fail ??
I don't get it anymore.
From 5 raspberries already 1 dead and 1 not having WiFi. All hardware issue occur during running on batteries, which power regulators.
Which one will be the next?

Made new Raspbian SD-card, boot ok, this one has BT active but no wlan0 ?
Weird as my old (updated) Rasbian does not even have BT nor wlan0? What is going on?

In my opinion, if hardware fails after 2 or 3 years working, not 1 error is logged the hardware looks crappy too me.
As all these issues do occur working on batteries, it is no option to use USB dongles to get WiFi working again, those take too much power.
Testing all this with a 3A powersupply does result in the same issues, no wlan0 at all, with no error in dmesg or anywhere.

https://www.youtube.com/watch?v=LSPXeEVGW4Q
Also did not work for the old or new OS.

https://www.youtube.com/watch?v=3SES2iPXnZ0
Also not working, the WiFi Country is greyed out, so can NOT be set on a clean Raspbian installation.

Weird is also the old OS has no BT (maybe swithed off in /boot/?) the new OS has BT.
On new OS BT and Wireless LAN can be swithed ON or OFF, but does not help anything, wlan0 keeps missing.

Opened an issue here.

DG.