Troubleshooting

@bjornhallberg said in RFM69 Range issues: Gateway (rfm69hw) initialization: #define MY_IS_RFM69HW #define MY_RFM69_FREQUENCY RFM69_868MHZ #define MY_RFM69_NEW_DRIVER Maybe I missed someone pointing this out, but the original poster's gateway initialization looks like it's missing something. These defines are not at all obvious, especially with the HW version. Strange things can happen, including unexpectedly low power. Check the API docs and also another thread. With the HW version of the RFM69 on the gateway, and the RFM69 new driver, in addition to what you list, you need to also include: #define MY_RADIO_RFM69 #define MY_RFM69HW true https://www.mysensors.org/apidocs/group__RFM69SettingGrpPub.html#gaf1455cd3427c9dc4c4564542c3dafc16 https://forum.mysensors.org/topic/11316/rfm69hw-atc-not-working

Sorry, but I'm afraid I can't help you any further. If the tests in the sketch do not go any further, there is something wrong with the board itself...

@Flyer Sorry, but I can't remember if I had any more problems after I manually fixed the database. And just a couple months after I had this problem I switched to Home Assistant instead.

Here is the schematics diagram.. thanks to @petewill for his original post and diagram. [image: 1612960353326-button-hack-n-channel-and-p-channel.jpg]

@Geelbuik it is a known issue, see https://github.com/mysensors/MySensors/issues/1458

I am going to rework the system so it uses an Easy Pcb and a Pro Mini rather than the Leonardo board. I think I might be seeing a voltage drop in my point to point dupont wiring from the Arduino to the Radio. I'll update you all once I get a chance to make the change. Bill

@skywatch Perhaps of interest, this possibility (lots of power cuts here in the early days) led me not only interface serial but power for the Gateway from the Pi header rather than separately, the current draw is tiny. The power cuts I later solved with a UPS but even before that it rebooted and went to work without issues, since the two reboot in sequence under the control of the Pi. As @Yveaux however has highlighted all my Nodes are fixed IDs.

I have both the uCurrent gold as suggested by @evb and also the "current ranger" https://lowpowerlab.com/shop/product/152 which is my first choice. It has a small display which makes it easier to use. But both are great products based on the same ideas from Evblog. Then to measure transient current you can hook up an oscilloscope to the output of any of the two.

great thank you for your answer! :+1:

You could send the blinds statess to Domoticz in the presentation method. My experience is that my setup doesn't like it when I send a lot messages to the gateway. So I use some small delays between each message I send from the node to the gateway, I didn't have time to look at your sketch. But here's some pseudo code: void presentation() { ... // the presentation code goes here. for ( int = 0; i < BLINDS_COUNT; i++ ) { send( message for blinds i, state of blinds i ); delay( 50 ); // or do less it's a bit of trial and error. } } In your case using random delays might be better, because you send 15 states with a delay of 50ms. So it takes at least 750ms to send all values. Adding the delay will also give other nodes time to interact with Domoticz.

"Usually" is the correct term. You can request whatever you want using MQTT, but you need to handle the response manually inside the receive() function. This isn't an automatic internal process like the echo or ack response. void receive(const MyMessage &message) { if (message.getCommand() == C_REQ) { switch (message.getSensor()) { case 10: // Send SSR 1 state break; case 11: // Send SSR 2 state break; case 20: // Send temperature sensor value break; case 40: // Send humidity sensor value break; default: break; } } } Note: It's best to not send a message from within receive() as it can cause all sorts of weird stuff, including recursive loops. Preferably, you'd set a flag and handle everything else in the main loop.

Welcome @mjchrist! Short answer: Check the return value of send() on the gateway, to see if a message has been successfully delivered an outgoing message (via Ethernet, MQTT, serial). Long answer: What you are referring to as an ACK should really be called echo instead to avoid confusion, because that is really what it does. bool send(MyMessage &msg, bool echo); If you set the echo parameter to true, you ask the destination node to echo the received payload back to the sending node. An echo is only being generated for messages that travel through the MySensors network. For example, if node 42 sends a message to the gateway (so that it can forward it to the controller), the gateway will echo the payload back to node 42. The same is true if the gateway is the sender and node 42 the destination. On the other hand, the boolean return value of send() will tell you that the sending node received an acknowledgment from the next hop. This next hop might be the destination if there's a direct connection between the two nodes, or any node that relays the message further to the destination, like a repeater. In the special case where the gateway sends a message (to the controller, so to speak), the return value of send() isn't the ACK from a MySensors-internal transport (like NRF24), but the confirmation that the message was successfully delivered via the outgoing transport layer which translates the message into a packet, a MQTT topic or string for the serial port. Oh, and by the way, please use isEcho() in favour of isAck(). The latter is misleading (IMHO) and deprecated. It will be removed with MySensors v3. And last but not least, MY_TRANSPORT_WAIT_READY_MS doesn't mean that the node (or gateway in this case) waits for n milliseconds until it starts establishing a connection (for the transceiver (NRF24), to be clear). Instead, it limits the time the node tries to establish a connection to n milliseconds, so that it can continue to work autonomously and do other stuff if it failed to do so.

@alexsh1 Thanks for the comment, there is some good tips there! I'll try re-soldering some of the connections. Funnily enough, I had wanted to increase the transmission power on 2 of my nodes (the furthest away from the controller) including this one here, and had added that at the top of my sketch. After uploading the sketch, the serial monitor still displayed a lot of garbage, but the node started successfully transmitting temperature and humidity values! So I've put the batteries back in and hung it up in the room, and it has been running pretty good so far. But I have my doubts how long it will last, given I didn't actually fix the serial output issue... On another note, is there anyway to confirm that the transmission power has been increased? I added #define MY_RF24_PA_LEVEL RF24_PA_MAX at the top of my sketch, just after defining the radio type, but it doesn't seem to have improved my transmission success rate (I realise there are lot of other factors affecting transmission success, but just wanted to check)...

@3nibble Diode is bad. You can shorting it. But then you can power this Arduino only from USB or from +5V in the same time!!! Not both !!! This can damage your USB port.

@skywatch I do have the resistor in place now, like mentioned it works and still works.:+1:

@Didou I know that cheap price is attractive, but in the long run it may not be the wisest path to take, especially with things connected to high voltages. When I mentioned the 4 'fake' power supplies back up this thread the thing that alerted me to be concerned was the fact that the power cables sent with them broke THREE electrical safety regulations in the UK. People are importing dangerous items and using them unawares. Its frightning really as there was even a case of a child being killed by a fake games console bad power supply. The risks are real. If you understand spoken English there is a TV program called 'Fake Britain' which i believe is on the web too. It follows investigations into all sorts of fake and dangerous items that get into the country. It's a very enlightening watch.

Thanks #define MY_NODE_ID n before(!) #include <MySensors.h> that helped a lot !!!

@mfalkvidd you're right. I've noticed it later, hadn't clicked on the link before. The project uses a uCurrent for calibration.

@joaoabs no, sorry. I didn't investigate any deeper.