No, but usually it can dissipate more heat and so it can be rated for more current if it's a power component.

https://aisler.net/

@MasonBlake yes, PA/LNA modules make a big difference. External antenna - not so much.

@kiesel I would look into ZigBee and/or matter. It's an industry standard, so won't be abandoned any time soon. Or you can try ESPHome if you don't mind using WiFi as a carrier.

@NeverDie you can try this https://github.com/cryinkfly/Autodesk-Fusion-360-for-Linux. I've set up bottle container for fusion and it works quite nice.

@moses https://github.com/mysensors/MySensors/blob/b9d9cc339659f724aa94d4108fc5289a720d1bcd/configure#L266
This is where you edit it. Just delete -mfpu=neon-fp-armv8 -mfloat-abi=hard and do

make clean
./configure

I'm not sure this will work, but I did compile mysensors for aarch64, just for another board and SoC.

@moses said in Compile on arm64 Raspi 3:

unrecognized command-line option ‘-mfpu=neon-fp-armv8’
unrecognized command-line option ‘-mfloat-abi=hard’

Try removing those flags from make file, apparently they are not needed for arm64.

@Multimax do you send initial states for all children for this multi relay node? HA won't show anything that hasn't sent initial data to show.
https://www.home-assistant.io/integrations/mysensors/#presentation

@electrik I am using MQTT explorer, but I don't see where is an option to see if message that was sent is retained. There is only box "retain" for a message to be sent from the program.

I wonder if anyone else have encountered this problem, and can explain why is it happening.
I was trying to increase frequency of PWM, so the first thing I tried, was lowering the prescaler for Timer2. By default it is set to 1/64 of F_CPU. I am running this particular node at 8MHz.

TCCR2B = _BV(CS21);

Setting prescaler to 0 or 8 leads to it being unable to receive any NRF24 messages, though it sends okay.

TCCR2B = _BV(CS21) | _BV(CS20);

Setting prescaler to 32 works normal, as does setting PWM mode to Fast PWM.
I've searched the Mysensors code and haven't found any mentions of use of Timer2 or interrupts connected to it.

I figured this out. After discovery, gateway sends states found in HA (or MQTT I'm not sure). It sends first - state, second - level. My code was turning light state on on every level change greater than 0, so because the state is sent first and the level second, my nodes got confused and turned lights on.
The question is why this behavior is different from TCP gateway I used before.
It was pretty dumb problem, but at least there is now this thread for someone who might have same problem in the future :)

Switching the gateway to 2.3.2 haven't change anything, as expected.

I have made myself a new standalone mqtt gateway (before I was only using RPi gateways). Now I see strange behavior with 2 of 3 light nodes I have.
After gateway boots, it sends discovery requests:

1296965 TSF:MSG:READ,0-0-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
1296973 TSF:MSG:BC
1297567 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=21,pt=1,l=1,sg=0,ft=0,st=OK:0
1299177 TSF:MSG:READ,0-0-255,s=43,c=3,t=4,pt=0,l=1,sg=0:1
1299183 TSF:MSG:BC
1299316 TSF:MSG:READ,0-0-255,s=63,c=3,t=4,pt=0,l=1,sg=0:2
1299322 TSF:MSG:BC
1299456 TSF:MSG:READ,0-0-255,s=16,c=3,t=4,pt=0,l=1,sg=0:3
1299462 TSF:MSG:BC
1299595 TSF:MSG:READ,0-0-255,s=30,c=3,t=4,pt=0,l=1,sg=0:4
1299601 TSF:MSG:BC
1299736 TSF:MSG:READ,0-0-255,s=239,c=3,t=4,pt=0,l=1,sg=0:5
1299742 TSF:MSG:BC
1299877 TSF:MSG:READ,0-0-255,s=192,c=3,t=4,pt=0,l=1,sg=0:6
1299884 TSF:MSG:BC
1300019 TSF:MSG:READ,0-0-255,s=145,c=3,t=4,pt=0,l=1,sg=0:7
1300025 TSF:MSG:BC
1300301 TSF:MSG:READ,0-0-255,s=112,c=3,t=4,pt=0,l=1,sg=0:9
1300307 TSF:MSG:BC
1300441 TSF:MSG:READ,0-0-255,s=18,c=3,t=4,pt=0,l=2,sg=0:10
1300447 TSF:MSG:BC
1305182 TSF:MSG:READ,0-0-3,s=255,c=3,t=6,pt=0,l=1,sg=0:M
1305313 TSF:MSG:READ,0-0-3,s=0,c=1,t=2,pt=0,l=1,sg=0:0
1305319 TSF:MSG:ECHO REQ

After this my nodes for some reason send current states:

1305323 TSF:MSG:SEND,3-3-0-0,s=0,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=OK:0
1305333 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=3,pt=1,l=1,sg=0,ft=0,st=OK:21
1305344 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=3,pt=1,l=1,sg=0,ft=0,st=OK:100
1305401 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:0
1305446 !TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=NACK:0

And after that they recieve it back from gateway, and act as if it was a command to change their state.

Gateway is 2.4 alpha, all 3 nodes are 2.3.2, and only two of them acts like this. I guess I am missing something, but can't grasp what exactly.

Any ideas?

@TheoL that's not the dimmer's fault a far as I am concerned. It behaves the same way at full brightness. It's just a cheap chinese driver in it.

@TheoL this is a basic triac control scheme, so it is leading edge type dimmer. I have led bulbs, that work with it, but they are clearly marked as dimmable. The downside of these bulbs is that they are very sensible to the slightest voltage fluctuations. I have not the most stable voltage on one of my phases, so it is very visible, unlike with the incandescent bulbs, that are connected to the same power source.

@TheoL there is nothing special in it :) In fact it's an old design that was waiting for the code to be written for a long time. And there are some issues with it. It seems that external interrupts for zero-crossing make NRF24 ACK fail most of the time. And if I were to make another one of this, I would add some low cost mcu to do the dimming part alone. I have dimmers with EPS8266 that uses Attiny13A for triac control, but I wouldn't try to make it control 4 channels.

Also the time of Atmega328 has passed, I guess. They are marked "Not recommended for new designs" by the manufacturer and I have struggled to fit everything I wanted (UI mostly) in it's memory. I ended up disabling serial output in mysensors and everywhere else, decreasing message buffer size and scraping bytes everywhere else I could to make it work stable without crashing.
I'm not sure if I will continue to make new designs for mysensors, but I think I will use NRF51822, as they are so cheap now at aliexpress, and you can add PA LNA to help with signal strength (theoretically, I haven't tried it). Another way is to use NRF52840 for all new designs, even they are 4-5 times more expensive than 51822 but later you can write a firmware for it to use Zigbee of Thread/Matter and use the same design with new functionality.

From left to right:

• Home Assistant server with built-in NRF24 radio and OLED display based on Orange Pi Zero
• MQTT Mysensors gateway with ESP8285
• 4 channel triac dimmer with oled display and UI for operating in standalone mode.

@GaryStofer well, if this is a timing issue, that's has to be on the Domoticz side. Probably it can't read fast enough?

@GaryStofer well, in that case you have to look at actual integration, and what Domoticz does not like with ack sent from node.

What debug outputs of a GW and a node show, when you send commands from Domoticz?

@GaryStofer said in Error sending switch command, check device/hardware !:

Also noticed that the GW code is not using the IRQ line from the radio, I see the SPI clock running on the GW constantly.

That's rather standard behavior.

@Zwippet the link you provided answers most of your questions:

That's the list of devices supported by rflink firmware. If yours aren't among them, I guess they won't work.

Mysensors work within it's own protocol and doesn't support any 3d party commercial products as per my knowledge.