Concerning RF24 Plus datasheet, it seems that a more recent version is available at https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf?cp=8_4_0_0

@alphaHotel A bit far from a compiler, so I don't test it, but did you try to define MY_DEBUG_OTA to TRUE ?

@mrhutchinsonmn Even if I know we're on a MySensors forum, you may also have a look to SigFox controllers (like MKR1200, should you want something with radio already built). Consumption if very low, and radio is off until you turn it on. You can be few hundreds of kilometers away from a base station and may use SigFox portal to send an alert to any device then (i.e. SMS).

@koewacko said in Reset values measured by Power Meter Pulse?:

I have looked everywhere in Domoticz how to reset the value(s) but i cannot find it.

As far I know, there's no way to remove only one value with Domoticz (as suggested, you can delete the sensor to destroy all values, but this may seems a bit aggressive ;-)

The way I do, when incorrect values are stored, is to modify Domoticz's database directly. As usual, you have to backup the DB before changing something, as doing it badly can just corrupt your DB, so your Domoticz (as almost everything is stored here).

Should you still want to proceed with DB changes, at your own risk, you may want to identify the sensor, stored in "DeviceStatus" table. As soon as you get the device idx (you may also find it on the Web interface), you should find the table(s) where data is store, which depends on device type. I don't have power pulse, so can't help you, but for energy meter, last day data is stored in "Meter" and historical data in "MeterCalendar". I usually change this table, either by modifying value and counter, or just deleting the row (depending on initial issue).

I've got a small Unix shell file that stops Domoticz, run a .sql file (where you have to insert your SQL orders) and restart Domoticz that I can share, on request.

@mfalkvidd said in Newbie wants to do everything wired:

MySensors with rs485 transport should fit your use case pretty well.

Getting back to your request, you need some kind of wired protocol to discuss between your sensors and your gateway.

Depending on cables you have, max speed of communication will vary. With UTP/STP CAT 5 or more, you may think about Ethernet. With less sophisticated cables, any serial protocol will do it. You may think about 2 end points system (RS 232) or multi-node (RS485).

As soon you have defined the physical layer, you have to think about the format of packets to be exchanged. Obviously, MySensors do it properly, and is already integrated (throughout gateways) to some popular controllers.

This is probably the reason @mfalkvidd advice you to use RS485 with MySensors ;-)

@yveaux : you're right! PIR are not so fast.

@yveaux: Would 30 seconds be a short wait time? ;-)

@alowhum: Perhaps something like

boolean sendWithPermission(MyMessage &msg)
{
  // Check permission and send here
  if (connecting_allowed){
    send(msg);
  }
}```

@alowhum said in 💬 MySensors Library - v2.x:

Being able to disable storing the routing table in memory.. implies that normally the routing table is stored somewhere else? In eeprom?

For simple network, with all nodes sending to gateway, this may just be ... nowhere, and systematically send to the destination node, without any routing.

You may also define static neighbor (like MY_NEIGHBOR_ID in the same spirit as MY_NODE_ID).

Any specific reason not using V_RAIN and send any float value ?

In addition to the remark on declaring sensor to Domoticz, the sketch itself seems to me a bit confusing.

Normally, you should do setup into setup function (stuff like pin mode, even eventually reading saved config and setting relay in correct state), presentation should contain only sendsketchinfo() & present(), loop should do the repetitive job.

You should avoid blocking the loop, especially if you want to receive messages (as you did).

You're using relay from pin 2 to 6 but sensor 1 to 5, but when receiving an order to set sensor x, you set pin x (instead of x+1). Result may not exactly be what you want/imagine.

You're turning pump off only when receiving a message (as the test is done here), instead in the loop.

You're using digitalWrite() on some analog pin (A1) ;-)

You're sending udpdates every 2 seconds, while sending either changes or data at larger interval may fit better.

In addition, you may also want to simplify:
send(msgNEPA.set(sensorState?"0":"0")) by send(msgNEPA.set(0)) (in addition, this will send numeric value instead of string, don't think that sending a string is what you want)

and

send(msgNEPA.set(sensorState?"1":"1")) by send(msgNEPA.set(1))

May I suggest you explain what you have, and what you want to do, for us to guide you setting the sensors properly?

Did you activate the child(ren) through the "Setup" > "Devices" list? If yes, the arrow on the child(ren) should be oriented to the left side. If not, activate them, giving a name. You'll then see them on the associated tabs. Note that device type depends on the type sent during presentation (so don't expect being able to declare device as a switch if you don't use the right child type)

... or you may want to connect the radio to one node, and link to the other by some means (like pins, serial ports, I2C ...)

Have a look, for example, to https://create.arduino.cc/projecthub/MajorLeeDuVoLAB/nano-i2c-io-expander-3e76fc?ref=platform&ref_id=424_updated___&offset=1262

Ad=s far I understand, we're speaking about radio ACK, which just confirm the right reception on the message, what could be sent. Then, that's gateway that can understand message contents.

If senders returns NACK, it just means that no radio ACK has been received from the other end within timeout (set to 1500 ms with MySensors' setup, running @ 250 kb/s, with 15 retries). That's exactly what happens when sending message and receiver off.

In the current issue, as you're on a repeater, you're in a good position to be in a position of receiving a message, and sending immediately another one (we can also have the same thing if implementing signature), were timing issues may happen.

I'll try to summarize, I do apologies if I didn't understand well:

• It seems that node 7 is properly discussing with gateway as soon as data is local,
• It seems that node 7 is not working properly when relaying data just received,
• It could also be possible that the second time node 25 sends the message, this may be due to not getting hardware ACK from node 7 to the sent message (remind that send timeout is 1500 ns, not so far from the 2 ms). Having a look to node 25 log could confirm this, showing a send ending with a NACK.

To fix the repeat of node 25, I would suggest adding a delay after receiving the message and before sending it to the gateway.

IMHO, when waiting for some time (1500 ns would be theoretically perfect giving current MySensors settings) after a write will cause issue for nodes that will write an answer to you, as you're still waiting after the original write, so you may think about waiting this delay before and after the write (the first one will ensure that the sender finished waiting for the ACK you sent to its write, the second one you received the ACK to your write).

As side effect, this could also fix the relay issue, as we're not protected against chance ;-)

@Snyfir: Maybe a timing issue in MySensors code? Are both node and gateway on the same kind of hardware?

It seems also (at least for me) that 2.3.1 may be more concerned by timing issues than 2.3.0, even if I don't saw in the code what could be the real cause. You may perhaps revert to 2.3.0 and see if you still have this kind of issue?

@grumpazoid: I had recently the same issue with a 2560 node and a Nano gateway. I fixed it putting a delayMicroseconds(1500) at (very) top of RF24stopListening function.

LOCAL void RF24_stopListening(void)
{
	// The following delay will allow this node to send an ACK to the last received message
	//	Value should be at least equal to ACR (1500 ms for 250 Kb/s transmission with 15 retries
	delayMicroseconds(1500);			//// *** FF_CHANGE *** //// 
	RF24_DEBUG(PSTR("RF24:SPL\n"));	// stop listening
	RF24_ce(LOW);
	// timing
	delayMicroseconds(130);
	RF24_setRFConfiguration(RF24_CONFIGURATION | _BV(RF24_PWR_UP) );
	// timing
	delayMicroseconds(100);
}

Don't know if your trouble is the same as mine, but hope this helps!

@Anticimex: Ok, I understand.

Would it be possible to imagine that, for gateways having more memory (as 2560 or ESP), in the same spirit as MY_RX_MESSAGE_BUFFER_FEATURE, having a sign buffer feature allowing this?

I should recognize that the event is not so frequent, so that's probably not a priority #1.

Making some extensive tests on message sending/receiving, I may have discovered some issue with signing.

This occurs when 2 nodes are requesting a nonce, while the first don't send signed message before second one asks for nonce.

Here's an example, with nodes 123 and 127:

0;255;3;0;9;891922 TSF:MSG:READ,123-123-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;891936 TSF:MSG:SEND,0-0-123-123,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
0;255;3;0;9;891959 TSF:MSG:READ,127-127-0,s=0,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;891974 TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
0;255;3;0;9;891982 TSF:MSG:READ,123-123-0,s=1,c=1,t=16,pt=5,l=4,sg=1:1
0;255;3;0;9;892011 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;892016 TSF:MSG:READ,127-127-0,s=0,c=2,t=2,pt=0,l=0,sg=1:
0;255;3;0;9;892022 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;894198 TSF:MSG:READ,123-123-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;894213 TSF:MSG:SEND,0-0-123-123,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
0;255;3;0;9;894243 TSF:MSG:READ,123-123-0,s=1,c=1,t=16,pt=5,l=4,sg=1:0
0;255;3;0;9;894272 TSF:MSG:ACK REQ
0;255;3;0;9;894277 TSF:MSG:SEND,0-0-123-123,s=1,c=1,t=16,pt=5,l=4,sg=0,ft=0,st=OK:0
123;1;1;0;16;0```

Is this a known issue? A restriction of current implementation?

@mfalkvidd: thanks for the pointer. For sure, I only did limited testing. However, I carefully read before the NRF24L01+ data-sheet, analyzed chronogram and tried to understand what may happens. But anyway, I must admit that I'm just a newbie in MySensors, and probably had wrong in the approach. Concerning Google spreadsheet, it's not able to understand VBA, and my code dirty code use it hardly ;-)

@Yveaux: I'm interesting by the reference in RF24 datasheet that may explain the delays I suppressed, to learn about my error, as I miss them. As of now, I'm thinking that RF24 with auto ACK is properly designed, with symmetrical switch delay of 130 us, except if you turn CE down before sending ACK of the just received message. As the ACK may be repeated, I choose to use the same delay as ARD, even if the probability is not so high. However, you're probably right telling that will break operations for other users. I'll let you decide if adding some delay at top of stop_listening function may help or not. And yes, I tried to apply your reco first, but it didn't worked. I suspect the other delays influencing the issue I had, but removing them all won't worked too. It only worked after adding delay before turning CE down.

Anyway, thanks to all for your help.

Last thing, is someone can tell me how to add [SOLVED] in front of my post, that'll be nice!