Posts made by FlyingDomotic

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!

@Yveaux: I fixed the issue. I removed all delayMicroseconds in RF24.cpp (except those in RF24_standBy), and added a delayMicroseconds(1500) on very top of RF24_stopListening. I tested with a Nano gateway + Mega node, a Mega gateway and a Nano node, and a Nano node and a Nano gateway. Everything is running smoothly.

Modified file is available (I tried to upload it on forum,, but "Upload file" was returning an error on file type, only allowing images.

Does someone know how to propose the change for a new version of MySensors (sorry, I'm something new on that kind of process ;-)?

In addition, I wrote a small Excel tool to decode MySensors log, mainly on TSF:MSG and RF24:* (see example of output here under). If someone is interested, I can push it by mail, but I would prefer making it available more widely. Is there any already existing way to do this (other than putting on my personal github account)?

@Yveaux: ok, I was not doing change at the right place. However, even at the right place, nothing changed. If I correctly understood, the proposed change only deals with "software" ACK (meaning the receiver re-sends back the just received value to the sender), while the issue on ping is the "hardware" ACK (RF24 acks the correct reception at radio level). However, this probably means that sender is not ready to read the answer (in this case, the nonce from the gateway).

I started reading RF24 datasheet. The only required timing I found are the 10 us CE should stay high at minimum in order to switch from standby to send mode, the 4 us minimum between CE up transition and CSR down and the 100 ms at power up.

I also understood that PA+LN version needs 10 us (hopefully, this is hidden by the 10 us of CE transition to high).

Did I miss something?

@Yveaux: I added the delayMicroseconds(1500) at top of rf24.cpp, and recompiled both node & gateway, but nothing changed...

LOCAL bool RF24_sendMessage(const uint8_t recipient, const void *buf, const uint8_t len,
                            const bool noACK)
{
	uint8_t RF24_status;
	delayMicroseconds(1500);	// *** FF_CHANGE ***
	RF24_stopListening();

I perhaps not properly got the idea...

@mfalkvidd Yes, I saw that, and already back ported the 2.3.1 change to 2.3.0, with great improvement in 2.3.0 reliability.
However, there's still something in timing with 2.3.1, at least when micro-controllers are not the same.

Hi,

I discovered a timing issue with MySensors 2.3.1 and NR24 "standard" (non PA, with capacitor and good power).

The gateway is a Nano with standard gateway. Signing is turned on. Basic debug is turned on.

All is working perfectly as long as the nodes are also on Nano.

However, this is not the case with Mega 2560.

This seems to be linked with the radio ACK of node PING request at startup. The gateway properly receives nonce request form the node, and answer to it, but always get radio NACK. Here's the node trace:

0 MCO:BGN:INIT NODE,CP=RNNNAS--,REL=255,VER=2.3.1
4 MCO:BGN:BFR
FF test sensor
V3.5.1/1.8.6/2.3.1
RNNNAS--
CE=49, CS=53, MISO=50, MOSI=51, SCK=52
46 TSM:INIT
47 TSF:WUR:MS=0
53 TSM:INIT:TSP OK
55 TSM:INIT:STATID=127
57 TSF:SID:OK,ID=127
59 TSM:FPAR
60 TSM:FPAR:STATP=0
62 TSM:ID
63 TSM:ID:OK
64 TSM:UPL
67 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2074 TSM:UPL
2077 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
4084 TSM:UPL
4087 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
6094 TSM:UPL
6097 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
8105 !TSM:UPL:FAIL
8107 TSM:FPAR
8109 TSM:FPAR:STATP=0
8111 TSM:ID
8112 TSM:ID:OK
8113 TSM:UPL
8116 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
10124 TSM:UPL
10127 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
12134 TSM:UPL
12137 TSF:MSG:SEND,127-127-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1

Here's gateway log:

0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGAS--,REL=255,VER=2.3.1
0;255;3;0;9;40 TSM:INIT
0;255;3;0;9;43 TSF:WUR:MS=0
0;255;3;0;9;51 TSM:INIT:TSP OK
0;255;3;0;9;53 TSM:INIT:GW MODE
0;255;3;0;9;56 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;60 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.1
0;255;3;0;9;64 MCO:BGN:STP
0;255;3;0;9;71 MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;74 TSM:READY:NWD REQ
0;255;3;0;9;112 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;329 TSF:MSG:READ,127-127-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;335 TSF:MSG:PINGED,ID=127,HP=1
0;255;3;0;9;375 !TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;2338 TSF:MSG:READ,127-127-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;2344 TSF:MSG:PINGED,ID=127,HP=1
0;255;3;0;9;2384 !TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;4347 TSF:MSG:READ,127-127-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;4354 TSF:MSG:PINGED,ID=127,HP=1
0;255;3;0;9;4393 !TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;6366 TSF:MSG:READ,127-127-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;6372 TSF:MSG:PINGED,ID=127,HP=1
0;255;3;0;9;6412 !TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;8375 TSF:MSG:READ,127-127-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;8381 TSF:MSG:PINGED,ID=127,HP=1
0;255;3;0;9;8420 !TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1

I'm thinking about timing issue as everything is getting well if I turn RF24 debug on on node. Here's gateway log (node log is too large to be included, but available on request):

0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGAS--,REL=255,VER=2.3.1
0;255;3;0;9;34 TSM:INIT
0;255;3;0;9;36 TSF:WUR:MS=0
0;255;3;0;9;44 TSM:INIT:TSP OK
0;255;3;0;9;47 TSM:INIT:GW MODE
0;255;3;0;9;50 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;54 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.1
0;255;3;0;9;58 MCO:BGN:STP
0;255;3;0;9;64 MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;68 TSM:READY:NWD REQ
0;255;3;0;9;106 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;15935 TSF:MSG:READ,127-127-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;15942 TSF:MSG:PINGED,ID=127,HP=1
0;255;3;0;9;15947 TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;15987 TSF:MSG:READ,127-127-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0101
0;255;3;0;9;15997 TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0101
0;255;3;0;9;16032 TSF:MSG:READ,127-127-0,s=255,c=3,t=16,pt=0,l=0,sg=0:
0;255;3;0;9;16048 TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=OK:<NONCE>
0;255;3;0;9;16102 TSF:MSG:READ,127-127-0,s=255,c=0,t=17,pt=0,l=5,sg=1:2.3.1
127;255;0;0;17;2.3.1
0;255;3;0;9;16134 TSF:MSG:READ,127-127-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;16149 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;16203 TSF:MSG:READ,127-127-0,s=255,c=3,t=6,pt=1,l=1,sg=1:0
127;255;3;0;6;0
0;255;3;0;9;18237 TSF:MSG:READ,127-127-0,s=255,c=3,t=26,pt=1,l=1,sg=1:2
0;255;3;0;9;18249 TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=16,pt=0,l=0,sg=0,ft=0,st=OK:

I didn't found any help on this forum, but tried to compare MySensor's RF24 code and Arduino's standard one, and found some differences on timing (the most significant one being after setting CE high or low).

Before starting modifying the code to (try to) find a solution, it may be clever to ask the forum first