Tried everything, factory reset, set up with and without sensors, router, smartphone, sensors and station right next to eachother. Put way too many hours into this and prefer not to waste the cost of the station and 4 sensors. Help!
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.
"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.
@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.
@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.
@evb I'm doing RFM69W based tests rights now. It would be good to compare figures about packet loss in a more scientific way.
Right now I am sending from 5 custom nodes (max 10 meters from custom gateway) every 30 seconds. That's 600 messages per hour.
I have a second gateway only listening on that frequency and counting messages. This 2nd gateway has missed 11 messages in 1 hour.
That's a packet miss rate of 1.8% (while RSSI is always stronger than -80 dBm).
A quick research in the internet shows ~1% should be more or less normal.
One thing that caught my eye was data whitening. If a message contains multiple zeros in succession, this can lead to the receiver not waiting till the end of the message.
Solutions: Using dating whitening or encryption.
paulsp........Any chance of getting a copy of your code you used? I really only want the nodes to send data to a pi zero, and the zero to send an mqtt message. I plan on doing everything else in node red and home assistant. Is that similar to your setup. Thanks!
