To follow up. It was hardware: broken vcc pin on the dht11 corrupted the whole sensor code badly. Resolder and added wait-code, inverted the on-off 0-vs-1 and I have a good working sensor. The duplicate is also installed and working reliably.
A 6-relay board is also working nicely and Domoticz is great. My old system is nearly replaced and I couldnt be happier.
Respect and thanks all around!
@Yveaux and @boum You two beat me by 2hrs.
@user2684 whose code this is (cudos to him, have used this bit on a number of sensors!) had probably figured that out and I screwed myself when I changed the original analogRead to int.
Now the whole thing works 100%
I've been looking into ESPnow and it looks good to me in many ways. Also the architecture would simplify building sensors.
I'm not a programmer at all, so I have no real idea of the scope of coding & testing this request would require. Or if the protocol could be suited to current topology.
But still, I wanted to throw this out there and hopefully get a response from someone who's better informed.
I have now. I always have that nagging feeling...
But after MANY iterations, finally success. At least partly. 
BlinkWithoutDelay works AND mysensors sketch as well (will do more testing...).
What made it work, if anyone else struggles with this:
-connect uno (to computer-linux), board:uno, upload ArduinoISP, disconnect
-add shield to uno and atmega328p-pu to shield, connect to computer, board: "8mhz on breadboard", "programmer: "Arduino as ISP", burn bootloader, disconnect
-board: Uno, connect as above, "upload sketch using programmer", disconnect EDIT this last part appears to work but internal clock is all messed up. Bootloader works fine like this.
The magic happened after I changed the board back to Uno after burning bootloader. Why is beyond me, but maybe some arduino-ninja can figure it out.
@gohan N00b question, but which steps from the step-by-step need to be redone to "compile it" after altering myconfig.h? Or can you just post the command lines? 
Nevermind. Whined too soon.
Completely worked over the node4 code, moved "include"s around and eventually changed the relay presentations and receive clauses. Hope this helps someone with their problems later:
Thanks a millions!
void before()
{
// Set relay pin in output mode
pinMode(RELAY_1, OUTPUT);
// Set relay to last known state (using eeprom storage)
digitalWrite(RELAY_1, loadState(CHILD_ID_RELAY)?RELAY_ON:RELAY_OFF);
}
later this....
present(CHILD_ID_RELAY, S_BINARY);
....and ending with this...
void receive(const MyMessage &message)
{
if (message.type==V_STATUS) {
if (message.destination == MY_NODE_ID) { // Only switch the relay if the message is for this node
Serial.print("Updating relay state");
// Change relay state
digitalWrite(RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF);
// Store state in eeprom
saveState(CHILD_ID_RELAY, message.getBool());
// Write some debug info
}
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}
@anticimex I've built a new node, DHT11 that sends temp&hum data. I reconfigured Rpi with this:
sudo ./configure --my-transport=nrf24 --my-rf24-irq-pin=15 --my-signing-debug --my-signing=password --my-signing-password=XXXXXX --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-user=YYYY --my-mqtt-password=ZZZZZ --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18
This is what I get in gw syslog:
Apr 2 22:53:11 DietPi mysgw: Starting gateway...
Apr 2 22:53:11 DietPi mysgw: Protocol version - 2.2.0
Apr 2 22:53:11 DietPi mysgw: MCO:BGN:INIT GW,CP=RNNGLSQX,VER=2.2.0
Apr 2 22:53:11 DietPi mysgw: !SGN:BND:PWD<8
Apr 2 22:53:11 DietPi mysgw: !SGN:INI:BND FAIL
Apr 2 22:53:11 DietPi mysgw: TSF:LRT:OK
Apr 2 22:53:11 DietPi mysgw: TSM:INIT
Apr 2 22:53:11 DietPi mysgw: TSF:WUR:MS=0
Apr 2 22:53:11 DietPi mysgw: TSM:INIT:TSP OK
Apr 2 22:53:11 DietPi mysgw: TSM:INIT:GW MODE
Apr 2 22:53:11 DietPi mysgw: TSM:READY:ID=0,PAR=0,DIS=0
Apr 2 22:53:11 DietPi mysgw: MCO:REG:NOT NEEDED
Apr 2 22:53:11 DietPi mysgw: MCO:BGN:STP
Apr 2 22:53:11 DietPi mysgw: MCO:BGN:INIT OK,TSP=1
Apr 2 22:53:11 DietPi mysgw: GWT:RMQ:MQTT RECONNECT
Apr 2 22:53:11 DietPi mysgw: connected to 127.0.0.1
Apr 2 22:53:11 DietPi mysgw: GWT:RMQ:MQTT CONNECTED
Apr 2 22:53:11 DietPi mysgw: GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
Apr 2 22:53:23 DietPi mysgw: TSF:MSG:READ,99-99-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
Apr 2 22:53:23 DietPi mysgw: TSF:MSG:BC
Apr 2 22:53:23 DietPi mysgw: TSF:MSG:FPAR REQ,ID=99
Apr 2 22:53:23 DietPi mysgw: TSF:PNG:SEND,TO=0
Apr 2 22:53:23 DietPi mysgw: TSF:CKU:OK
Apr 2 22:53:23 DietPi mysgw: TSF:MSG:GWL OK
Apr 2 22:53:23 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=8
Apr 2 22:53:23 DietPi mysgw: TSF:MSG:SEND,0-0-99-99,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
Apr 2 22:53:25 DietPi mysgw: TSF:MSG:READ,99-99-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
Apr 2 22:53:25 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=24
Apr 2 22:53:25 DietPi mysgw: TSF:MSG:PINGED,ID=99,HP=1
Apr 2 22:53:25 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=25
Apr 2 22:53:25 DietPi mysgw: TSF:MSG:SEND,0-0-99-99,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
Apr 2 22:54:18 DietPi mysgw: TSF:MSG:READ,99-99-0,s=1,c=3,t=16,pt=0,l=0,sg=0:
Apr 2 22:54:18 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=16
Apr 2 22:54:18 DietPi mysgw: !SGN:NCE:GEN
Apr 2 22:54:23 DietPi mysgw: TSF:MSG:READ,99-99-0,s=0,c=3,t=16,pt=0,l=0,sg=0:
Apr 2 22:54:23 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=16
Apr 2 22:54:23 DietPi mysgw: !SGN:NCE:GEN
This is kicking my butt... I cant understand that last part about the nonce 
I will add the code from the node as soon as possible.
Just a quick idea: are you powering the RFM69 from the Rpi?
I use a Rpi Zero W and when I powered my radio NRF24 from that it doesnt get enough juice even with caps.
I now use a bigger USB-wall wart and use AMS1117-3.3 to power the radio (PA-version) and added caps.
My two cents
@mfalkvidd Made the password 10 characters. From looks of the logs, it's working now.
I cant believe I skipped the step of making the password longer... Just got too fixated on the password I came up with.
Apparently sleeping less and debugging late solves problems. This is SOLVED.
My IDE library was outdated. I updated my Arduino Mysensors-library, upload to one node, and my node started to communicate fine. Must reupload all nodes unfortunately. Probably the problems are caused by signing differences in previous library versions vs. 2.3.0 release for Raspberry.
Again, hope this helps someone who encounters the same problem.
I never noticed the 20 device cap. That won't do.
What I am thinking of now, is to use EspHome and just dedicate a router to handle just that network - so kinda creating an IoT network without internet access and as standalone as possible. Using static IPs should make the response better too.
Thanks for looking into this.
I've been looking into ESPnow and it looks good to me in many ways. Also the architecture would simplify building sensors.
I'm not a programmer at all, so I have no real idea of the scope of coding & testing this request would require. Or if the protocol could be suited to current topology.
But still, I wanted to throw this out there and hopefully get a response from someone who's better informed.
Isn't 255 the child id for default battery level?
The code after is per log parser "!MCO:PRO:RC=1 Recursive call detected in _process(), call level=1"
I'd look in your code.
Also I can't figure out your setup from what you describe (rpi + nano via usb?)
Old topic, I know. Did anything ever come of this?
I'm also thinking it would be easy & cheap to get the espnow working as a transport layer.
I found this: https://www.mysensors.org/apidocs-beta/classESPNOW.html
But it goes above my head and abilities when it comes to code.
Check. Gotta redesign.
I'll get optos on the AC-voltages and power the Rpi from the 48/12V ground source.
Thanks for confirming my doubts.
If the grounds are connected: you mean I could connect them. Is it a bad idea?
When I really look at my goals, measuring is necessary only for the 48V line.
All the others I can get by with a on/off-info. Optocouplers for 240v data maybe?
The 48v and 12v probably have common ground considering the dc-dc converter? I'm not familiar with their design.
I need help with my build. I had what I thought was a great idea but now I'm having doubts & regrets.
I want to
The 240Vs each have a plug and a wall wart/phone charger plugged in.
I built a thru-hole pcb with 6 LEDs and voltage dividers for each power supply.
A Rpi Zero + MCP3008 reads the voltage dividers.
I connected the grounds (neg wires) on the chargers (4x) and hooked it to the pcb. I have leds light up. The 48v and 12v however don't light the leds (their gnd is not connected). The MCP3008 is not reading (the code could be wrong - just did a quick test).
As I was thinking about this, I got worried.
Can I connect all the grounds together (4x wall plug, 48V and 12V) ?
If not, what would be a good way to accomplish what I'm trying to do? I would like to read at least the solar battery voltage (40-57V) beacause that changes. The others can be on/off-type.
Any help or advice is appreciated!
OK. The fstab has credentials file and username password - I recommend picking one. Cred file probably more secure (but permission issues may arise again).
What I like to do is add my own log entries (into a logfile of my own - not syslog) into the script - to begin with, it logs all kinds of steps the program goes thru. That way I can figure out what makes it stuck - or go crazy otherwise. Then remove all the crazy logging once the script works.
Example from a shell script of mine of one of many lines marking up whatever steps:
echo "date -u InetReboot script" >> /home/pi/reboots.log
"Camera taking pictures constantly" does sound like bouncing..? Reading the button? Could be hardware. Maybe slow down the script also - add "time.sleep(50)" at the end?
I'm not sure but does python need the GPIO-definitions at the beginning?
i.e.:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
and maybe add a pullup/pulldown depending on your wiring.
Just some things to check (I'm NOT a linux ninja):
-crontab: why do "sudo crontab -e"? Would using just "crontab -e" use pi-users crontab and have less conflicting permissions?
-fstab has multiple credentials currently
-the launcher I believe has unnecessary lines (the changing directories)
-did you have multiple pythons? (bbt.py, doorbell.py?)
Just my two cents. Most of my problems are like this or permissions issues that just take too damn long to figure out.
Old thread, I know. Anybody know if this was ever fixed? I can get by with just open/close but percentage would be extra snazzy.
I'm using a 12V dc motor and microswitches at limit points. The blind is just SO heavy/dragging that I had to get a beefy DC motor. The apparatus moves nicely. Just the control circuitry to do.