@OldSurferDude If you have a pi2 or pi4 you could try with that instead of the pi3. Pi3 was known for being a bit 'different' with some applications. A quick and simple test if you can.

@TheoL That is kind of you, but no rush. I have not been building for a while now due to circumstances outside my control.

Maybe you could think of putting it on this site to help others too? Just a thought.

I will be interested to see what you have done and how it is working. :)

@sindrome73 From a recent upgraded node I do it like this....

if (dustAverage > 20.0 && dustAverage < 500.0) {
send(msgDust.set(dustAverage, 2));
wait(200);
}
send(msgQuality.set(dustStrings[x]));
wait(200);
send(msgTemp.set(temperature, 2));
lasttemperature = temperature;
wait(200);
send(msgHum.set(humidity, 2));
wait(200);
send(msgVOC.set(VOC, 2));
wait(200);
send(msgNOX.set(NOX, 2));
}

Hope this is clear!

Ciao.

Hmm, that is weird. I can only guess that HA and the pi are somehow responsible as they are the only ones that know the time.

I think you are saying that the nrf24l01+ is connected directly to your pi and that the gw runs on the pi?

I had issues with this setup and instead opted for a usb to serial module plugged into the pi usb port along with an arduino pro mini and nrf24l01+ as the gw. It has worked well for many years. Maybe an option for you to try if nothing else fixes the problem?

FWIW I am using 47uF * ceramic smd caps but always use delay to allow the data and power line to stablilse between sends.

*I like being different!

Just a guess, but check for any power saving or watchdog settings.

Post your code and a photo or diagram of your wiring.

Did it work before or is it a new build?

@Knightan

I believe that your problem may be related to this block of code. See my thoughts as comments....

 if (message.type == V_STATUS) {  //This is true for all messages received
   // Change relay state
    state_1 = message.getBool(); //This sets state for state_1 to the received value. 
    digitalWrite(LED_PIN_Channel_1, state_1?RELAY_1_ON:RELAY_1_OFF);
    // Store state in eeprom
    saveState(CHILD_ID_5, state_1);
    
     // Write some debug info
     Serial.print("Incoming change for sensor: STATE 1");
     Serial.print(message.sensor);
     Serial.print(", New status: ");
     Serial.println(message.getBool());
   } 

if (message.type == V_STATUS) {
   // Change relay state
    state_2 = message.getBool();  //This sets state for state_2 to the received value. 
    digitalWrite(LED_PIN_Channel_2, state_2?RELAY_2_ON:RELAY_2_OFF);
    // Store state in eeprom
    saveState(CHILD_ID_6, state_2);
    
     // Write some debug info
     Serial.print("Incoming change for sensor: STATE 2");
     Serial.print(message.sensor);
     Serial.print(", New status: ");
     Serial.println(message.getBool());
   } 

It seems to me that state_1 = message.getBool(); AND state_2 = message.getBool(). So they both get set to the incoming value.

I think you need to not set both to the same value and instead differentiate them to unique values. I could be wrong as I have not had chance to do anything related to mysensors for a long time now - I also don't use Domoticz.

Have a look at the code on this page, it might help you a lot.... https://www.mysensors.org/build/relay

You need to know a little about the VOIP protocol in use by your service provider. Then you can get the Session Initiator Protocol. With this info it may be possible to monitor the ip traffic on the line, sniffing for this to send your beacon message. Be advised I know little of this and have never tried it myself.

Welcome - I hope you find it inspiring, educational and practical. There is lots to learn and more to achieve.

@TheoL MySensors is not tied to the atmel328. It works on other MCUs too. I do agree with not wanting anything in the cloud, on wifi or bluetooth for security reasons.

It is not clear what will happen next - no announcements about what the intentions are for either the site or the project code. I guess time will tell.....

@Commodoreuno I can't see anything obvious at a quick look through, but I would suggest that you change all the delay() functions to wait() functions and comment out the serial print instructions and see how it goes then.

Does anyone have any suggestions for a 'directional' human presence sensor?

It needs only about 3-4M range but a 90 degree field of view would be ideal for corridor doorway detection.

I have seen some listed online but I believe that they have a 360 degree sense area and this would not be suitable for my application.

Well I was very saddened by the news that MYS site was shut down.

Yes there are alternatives but the flexibility to learn and develop independently without the data spying used by some big business was a huge plus for me. Having all the data at home and the ability to mix and match sensors tailored exactly to my requirements was just the job!

There were areas where this site could have been improved and that could have made more people stay and learn.. I think most new users gave up in frustration after just 2 or 3 posts.

I never heard of Code Garage before, but thank you for this bold move and long live my sensors!

Nice work there!

Thank you for sharing your success, I am sure there will be others who have an interest in this type of set up.

I found this if it is of interest (or not)...

https://www.hackster.io/TMRh20/iot-home-automation-w-nrf24l01-raspberry-pi-9ee904

@kiesel This is just my impression, nothing has been announced so it is guess work. But it took a week to get even one response to your question, and that says a lot.

Nothing comparable that I know of, but this all still works just as it always did and I have invested too much in hardware to leave it all and risk the same thing happening again.