Are you sure, the sending part of your hardware is working?
In the past I successfully used a comparable code to hard-shovel's proposal (although with a different IRlib).

As you mentioned the "code" seem to be ok in decimal writing, a hardware defect imho is the most likely cause of your headaches.

@koniu said in another sensors connection via usb ?:

@rejoe2 Thanks, it works only with different USB-serial converters - for the same mix children

Sorry, but I don't get your point.
It also works using two CHG340-Nanos, but eg. in FHEM you best would distinguish them using the output of ls -l /dev/serial/by-path

And also when using two different converters it would in any case make much sense to use different ChildID's to avoid mixing up the data from both Nodes.

@koniu In general this is possible. Both mcu's have to be configured as a gateway, so you may base your code on the serial gw sketch.
BUT: Handling multiple GW's is not supported by all controllers and using 2 mcus with a CH340 USB-serial converter (in case your nano is also equipped with that type) may be tricky to handle in Linux as they seem to be identical for udev etc.
Wrt. controller: E.g. FHEM soports multiple GW's but will mesh all incoming data in one Node and can only use one of them as an adress for active commands like switching relays or set initial values for counters. So at least use different Child ID's for your "S"-es on both mcus

It's pretty easy to send back the actual state of the relay.

But imho there are several options to improve the behaviour of the whole thing:

• if it's more secure to start the whole thing with the relay switched off instead of reading value from EEPROM. Then ask the controller about the desired state and keep it off until message arrives or button is pressed?
• keep track of the actual state of your relay within the loop(). By now, the switching logic of the button/switch seems to be weired. Does this work as expected?
• if it's a security function: let the node decide whether the relay should be switched off, dependend on the meassured value and the state of the relay. Just inform the controller it had been switched off.

It might be necessary to add some overriding functionality (eg. keep relay on for x minutes if it has been switched on using the button and so on).

@pdp8 Despite not beeing familiar with domoticz, this behaviour seems to be logic to me: You presentet a light device, so this typiclly is switchable from controller side.
You might either change the handling within domiticz or present a different Child Type (my code uses motion).

Seems to be a good starting point, but some remarks:

• Using PINs 10-12 might not be the best choice in case you want to add a radio later (my code was for RS485@HWSerial)
• Doing this kind of task using arrays gives much more flexibility and easier reading imho

So essential Part of the sketch could be reduced to something like (untested, changing PINs recommended):

...
#include <Bounce2.h>

#define FIRST_PIR_ID 1
#define MAX_PIRS 3 
const uint8_t pirPin[] = {10, 11,12};   //  switch around pins to your desire
Bounce debouncer[MAX_PIRS];
MyMessage pirMsg(0, V_TRIPPED);
bool oldPir[MAX_PIRS] = {false};

void before()
{
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo(SN, SV);
  // Fetch the number of attached temperature sensors

  for (int i = 0; i < MAX_PIRS; i++) { //i < numSensors &&
    present(FIRST_PIR_ID + i, S_MOTION);
  }
}

void setup()
{
  for (uint8_t i = 0; i < MAX_PIRS; i++) {
    debouncer[i] = Bounce();                        // initialize debouncer
    debouncer[i].attach(pirPin[i], INPUT_PULLUP);
    debouncer[i].interval(5);
    oldPir[i] =  debouncer[i].read();
  }
}

void loop() {
  
  bool pir[MAX_PIRS];
  for (uint8_t i = 0; i < MAX_PIRS; i++) {
    debouncer[i].update();
    pir[i] = debouncer[i].read();
    if (pir[i] != oldPir[i]) {
      send(pirMsg.setSensor(FIRST_PIR_ID + i).set( pir[i])); // Send tripped value to gw
      oldPir[i] = pir[i];
    }
  } 
}```

Just concentrate on the looping over arrays logic, then it's not that hard to break the link between the buttons and the relays. Did this myself here, despite having a lot of other stuff done there maybe this helps

IMHO this is a good starting point: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33

@pictor-lallemand You may also have a look at the sketch @korttoma published in post #33. It does exactly the same than yours, but in case one needs more or less relays, it's much easier to adopt .

Interesting project. As I'm just a hobbyist, there might be be better solutions and thoughts, but that's what I know:

First: I assume, in case of yarn breakage you will have to stop the machine and some human will have to fix the problem - so some kind of lokalization of the breakage would be sufficient? => Put an array of hall sensors to be easily checked with one view in parallel and use hall sensors that will be switched on in case of breakage. This reduces the amount of PINs or other detectors needed.

As I'm not familiar with the mentioned D2401: Just order some of them for testing... Don't know how fast they are, but wrt. to 1-wire Temp sensors I know 1-wire is at least capable for some dozents of them on one bus. Several buses in parallel are posible, bt then memory might become an issue.

You may also have a look at port extenders like the MCP23017: this gives you more PINs over a simple I2C connection, several of them may be used on one arduino (no experience with that). They offer interrupts also afaik - if speed in reaction is needed. Most likely you might need a more powerfull mcu - then have a look at the STM32's (but avoid blue pill in favour of maple mini-compatible solutions).