The Serial Gateway on an Arduino is probably the easiest gateway to employ. The problem is that it has to be connected to the computer that is hosting the controller. In my case, the host computer is in a place that blocks radio signals. The communication will be degraded with a long cable.

Using an ESP8266 gateway is an obvious choice when the radio (eg nRF24) needs to be in a different location. Wire the radio to the ESP board. If your using and ESP-12(E/F) you'll have some more wiring as described the the document Installing Gateway Software

I find that using C++ programs for the ESP devices can get pretty convoluted. I prefer to use Tasmota for ESP devices. The Tasmota firmware can be updated Over the Air (OtA). Yes, you can add OTA to C++ programs, but my experience is that the mDNS is finicky. With Tasmota, configuration is done through the device's web page. And coding is much more simple; for this example, the configuration takes two lines.

The downside of the ESP-12F is that 5V always causes magic smoke to escape. Arduinos are much more tolerant and have more ADC ports.

Thus I ventured into creating a Wireless Serial Cable. I use Home Assistant to which I will be referring as HA. This will probably work with other controllers. I had a lot of help from the HA forum and detail the how to create the Wireless Serial Cable there.

Here I would like to share the Wireless Serial Gateway.

If you're using an ESP-12F, you'll need 3.3V power supply. The Arduino Nano needs a 5V supply, not the USB connector because the USB serial will conflict with the serial going to the ESP device

The ESP device has Tasmota ZBBridge installed (ZBBridge32 for ESP32)
configuration is:
Set module to Generic
Set GPIO15 to TCP TX and GPIO 13 to TCP RX (17 and16 for ESP32
From the ESP device command line

Rule1  on system#boot do tcpstart 8888 end on
rule1 on

then restart with

restart1 1

On the HA side install the TCP gateway (not the serial gateway)
using the IP address of the ESP device and the port as 8888

The Arduino may need to be reset to send over the initial gateway information.

@Eliza-Collins Thank you for a more knowledgeable explanation! When I wrote:

said in Imitating a LoRaWAN(R) with ESP8266/ESP32 and MySensors:

with a number of compromises

You filled in some of my nebulus's with:

@Eliza-Collins said in Imitating a LoRaWAN(R) with ESP8266/ESP32 and MySensors:

ADR, security, scalability, and multi-gateway roaming are among the issues that LoRaWAN resolves.

Thanks for pointing these out

Good project. Let us know how this works out for you!

I tend to agree with @sindrome73 in that MySensors is pretty awesome as it is. Recently in the Home Assistant forum there was a discussion on adding an Arduino to an ESP device to get more I/O. Convoluted, arcane scripts were presented for various classes of sensors. I noted that once the MySensors environment is set up, adding a new sensor is very simple: read sensor, send data

But there are new and more capable devices than the Arduino and nRF24 radio. Development should be seriously considered into incorporating more of these devices.

Also, I see a trend that people new to DiY/IoT expect everything to work out-of-the-box. The corporate interests have seized upon this trend, offering devices that are easy to connect but have the ulterior motive of collecting data on the consumer, which is way more profitable than just selling the product.

It really comes down to us, the grass roots people, to support any and all comers to MySensors. Personally, I am not an expert, and not being one, I try to research challenges and present possible solutions from that research. I learn a lot doing thins. The more people we have coming here, the better it will be. Maybe we can pique the interest of some very clever, inspired innovator to join us.

Like Kennedy said, "Ask not what your country can do for you, but what you can do for your country."

-OSD

Great! You got it to work! And it looks professional, too! Good job!

I just did a google search and found that the Legrand 4124 00 is a (noiseless) latching relay and the input is referred to as a "coil". This means to me that it is a mechanical relay, not an SSR. You should be able to drive it with an SSR.

Now the latching part. The Legrand 4124 00 needs a "pulse". It appears that the switch you are replacing is a push button, (closed only while holding the switch). This means that your Arduino must
pulse the SSR, turn it on and then, a second or two later, turn it off.

Is that what you are doing?

Unfortunately, your Arduino won't know if the light is on or off.

--------- other thoughts but not very good ones
According to this article, SSR's inputs are opto-isolators. If I read the specifications correctly, the input voltage is less than 0.1V (<100m) and the short circuit current is 50mA.

This means that you may be able to drive your Télérupteur Legrand with another optoisolator (for example PC817) which is driven by your Arduino. (The specs say that the input to the optoisolator needs 50mA, the Arduino specs state that it can only supply 40mA, but I have had success with doing it)

BUT You have measured Retour BP to L at 150V. The optoisolator I note cannot handle 80V Collector to emitter but only 6V emitter to collector.

Which led me to what I wrote above.

It seems you should be able to do that. I found this, "Voltage/Current Matching: The control output of the first SSR must match the required input voltage (and current) of the second SSR's control side." Most likely there is insufficient load on the output of the Arduino driven SSR to have it function.

Why not use a mechanical relay? The current you would be switching would be very, very small which means the relay would last a very long time.

And a Scintillating Solstice :)

sure:

#define Ver 2.0

#include <EEPROM.h>

// ver 2.0 range 0 through 255

// ------------------------------------------------------------------------------------clearSerialBuffer
void clearSerialBuffer(){
  while(Serial.available()){
    Serial.read();
    delay(50);
  }
}
// ------------------------------------------------------------------------------------header
void header(){
  uint8_t EEpromInt = EEPROM.read(0);
  Serial.print(F("Current value at address (0) is "));
  Serial.println(EEpromInt);
  clearSerialBuffer();
  Serial.print(F("Enter a an unsigned integer >=0 and <=255: "));
}

// ------------------------------------------------------------------------------------setup
void setup() {
  Serial.begin(115200); Serial.print(F("\n\rAddress As uint8_t ver ")); Serial.println(Ver);
  clearSerialBuffer();
  header();
}
// ------------------------------------------------------------------------------------loop
void loop() {
  
  if (Serial.available()){
    long inInt = Serial.parseInt();
    if (inInt <0 || inInt >255){
      Serial.print(F(" I don't like '"));
      Serial.print(inInt);
      Serial.println(F("'"));
    }
    else {
      EEPROM.write(0,uint8_t(inInt));
    }
    header();
  }
}

This is very cool. In order to provision my devices, I had two programs. I loaded the first that was used to set MY_NODE_ID in location 0 of the MyEEPROM (this is where MySensors puts it). Then I would load the MySensors program.

The sCmd library is much better, though it would take up program space.

I concur with @TheoL, though I understand the desire to have better control over your interface. The MySensors serial interface is well documented. You might consider MQTT as a transport mechanism. MQTT Explorer allows you to view the data which makes debugging easier.

Good luck with your project.

I discovered the source!

When I execute

crontab -e

I am editing the user cron table.

sudo crontab -e

edits the root cron table. That was where the restart at midnight was.

When I was accessing the gateway (via ssh) I was user. I am running headless, which is running as root and a user instance only runs when I ssh into it, which means that editing the user cron table does not do anything (unless a user instance is running).

My guess is that the the leakage power captured can only supply that amount of current (at the specified voltage)

I would say the 2W should be used. I say this because it would be exceptional to spec 2W and there is probably good reason to do so, though I do not know that reason.

Often times people with experience with the design reason that a different value will work. Or they find that the component doesn't mechanically fit into the modified design. (I will admit to doing this myself) I suspect that the resistor periodically is dissipating 1W (1W of tolerance). If this is the case, after many cycles, even years, the 1/2W will fail.

I will share some experience. I put 2W (12V/0.15A) into a 2W resistor. I went to pick up the board and grabbed it by the resistor and burnt the crap out of my fingers.

Overdesigning is good. Cautionary tale: Mrs. Fiorina told the printer mech designers that they make the printers too good and that they should make them cheaper. The company of which she was CEO is not doing so good today.

The distance to my sensors would be 20-30M through a fire separation wall, four interior walls, a ceiling and an external wall.

I, too, have done some experiments with the RFM69 and had the same experience. But they are about 10x the price of an nRF24. ($6.80 vs $0.68) The cost of the RPi zero 2W is $15 (though I've had two where the WiFi chip failed).

The LNK364 has an internal 6.3V zener diode across BP and S so the 10V is OK, though the 50V is probably a better idea. The data sheet indicates the capacitance should be 0.1 μF (100nF). I'd recommend the latter. (It could be a typo in the EasyEDA)

@skywatch @sindrome73 This is what I do, too.

Note that it is wait(), which is a MySensors function and not delay(), an Arduino function. wait() checks for MySensors messages, delay() halts all process, thus a message might be missed.

Yes, nRF24 is attached to the RPi3B+ on which the gateway runs.

I have long considered an Arduino Nano with nRF24 connected to the computer that runs Home Assistant. This probably would not work because the sensors are in the backyard and the HA computer is in the garage which is at the front of the house.

I have configured the Nano to be a gateway sans radio to which a sensor is connected. This is a very effective way to give the computer some I/O!

I will consider it for future designs. For now, "if it ain't broke, don't fix it."

(I, too, hate delays)

@mfalkvidd

This statement is the crux "It just needs to expose its capabilities in a form the AI can use".

The IoT device would have to present its capabilities in MCP-ese. This could be complex, for example, one could tell the AI, "Heat my house in a way minimizes on/off cycles." It would have to know a large number of things, temperature (indoor, outdoor, outdoor and indoor heat transfer fluid), fluid flow rate, fluid pressure, indoor and outdoor fan speed, how to regulate those speeds, and more.

What I think I'm trying to say is that it will create more overhead.

And this AI, where does that reside? If not in the cloud (the cloud has its own set of negatives), then on a home server? ... yet more overhead.

It seems like instead of simplifying our lives, it would overly complicate them.

Of course, I guess, we could ask AI to design our IoT devices :o

-OSD