Posts made by tante ju

I think I found a way, maybe an idea to document it somewhere?

If the C_REQ received has getLength()==0, it is a request for a value. If it has any payload, it is reply to a request.

Makes sense?

@Sasquatch said in How to properly handle variable requests:

I see it this way:
NodeA sends C_REQ of Var1 to NodeB
NodeB processes C_REQ message in receive();
NodeB replies with C_SET of Var1 to NodeA just as controller would
NodeA processes C_SET message in receive();

You can use echo/ACK functionality or not, it doesn't matter.

If you want both nodes to synchronise their variables, then it seems best to:
a)request values on boot
b)On variable change send values without prompt

That way you cut traffic by half compared to request-reply approach.

In case of vars to be synced that could be an approach. But in case, that is not intended, the C_SET looks for NodeA as a request to modify Var1 in NodeA.

@Boots33

Node to Node. Between Nodes that have the same set of Variables.

@Boots33

I don't see any of the posts addressing the core issue.
You could have different actions regarding variables:

1. set variable in destination node
2. request variable from destination node
3. deliver variable from source node

3 is a result of 2. In controller/node communication 3 is no issue, as it could just C_SET (as it would be with 1), because I think it is unlikely that a node wants to set a variable in the controller other than its own variable representation.

But for 3 between nodes: How to differentiate it from 1 and 2? I could not find any standard or best practice approach. All the ones I found are based on assumption of using different variables in the nodes or that a node could not set a variable in another node (and hence could use C_SET as answer) or that the request is always from the controller.

Hello,

I've seen this ask several times, dating back to 2015 or so, but no really appropriate answer. Hence I try to find a definitive answer to this question.

How to properly handle requests of variables in the nodes?

According to documentation the request(...) function could be used to request variables from the controller or any other node.

What it does is sending a message with command C_REQ. But how should an answer properly be sent?

Example (shortened to what is really important here):
Node 1 has a variable V_STATUS, Node 2 has a variable V_STATUS.
Node 1 now septs C_REQ for V_STATUS to Node 2.
What should Node 2 answer?
If it would answer with C_REQ, this could be read by Node 1 as request for its V_STATUS. If it would send C_SET it would be a set of V_STATUS in Node 1.

Only reasonable way I see with available tools would be:
Node 1 sends C_REQ for V_STATUS to Node 2, with EchoRequest (because it is for sure requesting for something back), payload is empty.
Node 2 replies C_REQ for V_STATUS, puts V_STATUS value in payload and sets isEcho.

Problem with this approach: The echo request is not seen in the receive function as it is handled in transportProcessMessage() inside library. Plus: This would stretch the definition of echo, because the answer is not an echo, as it has payload the request did not have. But that would probably be acceptable, because an empty payload would still be an echo in case Node 2 does not have variable V_STATUS.

Did I miss anything?

Hi,

I have quite a MySensor network running, but all with old software. Now, in preparation to do software upgrades, I have a small test setup here with one gateway and one test node and this signing now gives me some headaches.

(beside bugs with presentation(x,x,true) and the store_xx_key_data in SecurityPersonalizer befing inconsistent between declaration and implementation)

So, here is this setup.

1. GW on ESP8266 with NRF24L01+
   Personalized with HMAC, AES and Serial not used.

#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES

This is the output after boot:

51 SGN:PER:OK
53 SGN:INI:BND OK
55 TSF:LRT:OK
56 TSM:INIT
57 TSF:WUR:MS=0
64 TSM:INIT:TSP OK
66 TSM:INIT:GW MODE
68 TSM:READY:ID=0,PAR=0,DIS=0
70 MCO:REG:NOT NEEDED
scandone
78 TSM:READY:NWD REQ
81 SGN:SGN:NREQ=255
111 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with MSHOME, channel 6
dhcp client start...
578 GWT:TPC:CONNECTING...
1080 GWT:TPC:CONNECTING...
1582 GWT:TPC:CONNECTING...
2084 GWT:TPC:CONNECTING...
2586 GWT:TPC:CONNECTING...
ip:192.168.0.209,mask:255.255.255.0,gw:192.168.0.1
3088 GWT:TPC:CONNECTING...
3090 GWT:TPC:IP=192.168.0.209
3093 MCO:BGN:STP
3095 MCO:BGN:INIT OK,TSP=1
3097 GWT:TPC:IP=192.168.0.209
3100 GWT:RMQ:MQTT RECONNECT
3116 GWT:RMQ:MQTT CONNECTED
3119 GWT:TPS:TOPIC=sensorgw3/0/255/0/0/18,MSG SENT
3124 GWT:TPS:TOPIC=sensorgw3/0/255/3/0/11,MSG SENT
3129 GWT:TPS:TOPIC=sensorgw3/0/255/3/0/12,MSG SENT
3134 GWT:TPS:TOPIC=sensorgw3/0/10/0/0/20,MSG SENT
pm open,type:2 0

Now starting a test node (Testnode example) with same HMAC personalized and signing request configured, the gateway throws this out:

171436 TSF:MSG:READ,11-11-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
171441 SGN:SKP:MSG CMD=3,TYPE=16
171445 SGN:SKP:MSG CMD=3,TYPE=17
171449 TSF:MSG:SEND,0-0-11-11,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
171456 SGN:NCE:XMT,TO=0
171500 TSF:MSG:READ,11-11-0,s=1,c=1,t=0,pt=7,l=5,sg=1:27.60
171505 SGN:BND:NONCE=F3E1CCE7E2378EF0EA2F68918358CA79EE390857981324F47EAAAAAAAAAAAAAA
171514 SGN:BND:HMAC=289313013D106B2F1645B73284843953F80D23E663C37906BCD4D433339CA760
171521 SGN:VER:OK
171523 TSF:MSG:ACK REQ
171525 SGN:SKP:ACK CMD=1,TYPE=0
171556 !TSF:MSG:SEND,0-0-11-11,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=NACK:27.60
171563 GWT:TPS:TOPIC=sensorgw3/11/1/1/0/0,MSG SENT
181770 TSF:MSG:READ,11-11-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
181775 SGN:SKP:MSG CMD=3,TYPE=16
181779 SGN:SKP:MSG CMD=3,TYPE=17
181783 TSF:MSG:SEND,0-0-11-11,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
181790 SGN:NCE:XMT,TO=0
181834 TSF:MSG:READ,11-11-0,s=1,c=1,t=0,pt=7,l=5,sg=1:27.30
181839 SGN:BND:NONCE=4ABD55D7A58D5C496030C98FDDE3307FF6C2EBEFAF4BADE133AAAAAAAAAAAAAA
181848 SGN:BND:HMAC=880BE3BE6DFF6B64BC451C9E186C112A940F825A48272EEB8AD585F0A21C61BD
181855 SGN:VER:OK
181857 TSF:MSG:ACK REQ
181859 SGN:SKP:ACK CMD=1,TYPE=0
181890 !TSF:MSG:SEND,0-0-11-11,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=NACK:27.30
181897 GWT:TPS:TOPIC=sensorgw3/11/1/1/0/0,MSG SENT

So, messages from the node arrive, are verified, forwarded via MQTT but the ACK is never sent back. Signer says, ACKs are not signed (SGN:SKP:ACK), but why is it then not sent plain text?

Am I missing something here?

Hi,

Following setup:
ATmega328P with NRF24L01+ and MySensors 2.0.0 sketch on it,
NRF connected to hardware SPI, CE on D5 instead of D9 (Arduino numbering) and CS on D6 instead of D10.

Everything is set correctly in the sketch, but still D10 will be initialized and put high, although not used.
The right CS pin will be used later, but this initialization of D10 is just wrong.

If I enable SoftSPI and set the D11-D13 as the ports to be used (so, using same ports but bit banging instead of HW), everything works correctly.

Had a quick check in the sources, but could not find where D10 is initialized.
This effect vanishes, if I change the default setting in the MyConfig.h

Tested with Arduino 1.6.9 and 1.7.10.

@Tore-André-Rosander said:

@tante-ju Some sort of cache problem? I had a similar issue with the beta, i used the clear eeprom sketch on the node and set a different node id manually and fixed it.

EDIT: Had the same problem now with the v2 release, clear eeprom on the node solved it

Hi, as the same type of old code is written in a new proc, it could not be the EEPROM. The Arduino environment together with the new MySensors lib seems to build some object files only once and then uploads them all the time.

I like the new setup of the MySensors lib, but after getting some more gray hairs and replacing processors, boards and all the other stuff I noticed, there is something wrong with it.

Following effect (tried it with Arduino versions 1.6.3 up to 1.6.9 on a Mac with El Capitan):
I've setup a clean Arduino environment and installed the new MySensors lib. Wrote a program, where I wanted to test some interrupt routines with MySensor and it did not work. ok, seemed to be a bug and watchdog stepped in. Fixed software, rewrote software, created a small test program and always the same issue. I used Node Id 5 for this one.
Then, after a whole day and changing processors and all other stuff I loaded a file, working with 2.0-beta and using Node Id 7. And what I got where the same messages on the gateway, just with Node Id 7. ???
In fact I got a presentation of HUM (my tests with Node 5), but with Node 7, although the file never had anything to do with HUM.
Verseifen with an Arduino Nano board, installed a very small MySensor example script on it and same effect.

So, some pieces of the initial program were once compiled and resided in the system, regardless what source you are using afterwards.

Deleted the new 2.0.0 lib, installed my 2.0.0-beta and everything is fine. Switched back to 2.0.0 stable and instantly the old binary was back there.

Any ideas?

I'm in favor of this.

I would add Item 6: Have (configurable) symbolic names for the values.
I' using the gateway with FHEM where readings are automatically created and symbolic names are much easier to handle than the raw numbers. I've pacthed that in the version I'm using, but a general approach would be great.

@ahmedadelhosni said:

My questions:

• Is this normal ? Would that affect the Atmega and other components ?
• How to avoid this ?

This is a matter of reference. When you have a power source with no contact to any othe rreference you are safe to touche one contact of that power source. If you make contact to the other one, you would be a resistor to the power source and act as esistor, having current runningthrough your body with all the negative impacts, including chance of death.

As explained, that is a matter of the reference. When you use a transformator, where secondary is not connected to anything else, you could safely make contact. In case you use any transfromless design, everything is somehow connected to mains. You are connected to grounds, so touching anything would be dangerous. As long as you do not touch anything, you are safe.
In fact a lot of electronics is tranformless with enough and safe insulation around it, so that no contact to grounds is possible. It is not only affecting persnal health, but could also be a source of fire if there could leak any current to grounds or mains from that circuitry. That's the reaosn for the insulation.

In fact this applies to transformators as well, as the primay side has contact to grounds.

So, it does not affect any Atmel or so, it just raises the level of security precautions you have to take care of for this type of circuitry.

@hek
That thread does not directly touch on the issue I noticed, although that might be connected.

Some other questions:
Why is the topic structure as it is? I like my MQTT topics in hierarchical order. So, having different prefixes for send and receive (in and out) is not nice, but ok. BUt why is the ACK flag before the data type, which is usually linked to a value or variable in the sensor? I would consider ACK to be a sub-value of that one.

And is there a way to have more speaky names instead of numbers? So, the source does not have that option and as that gateway is now included in the library I only see the possibility of changing the source in the library, which will disconnect from updates. Not nice. What about an option of excluding gatewayTransportSend and incomingMQTT via define from the library and define then in the own sketch?

Hi,

Just tried to set up an ESP-12E as MQTT gateway and noticed one bug in the actual development branch:
As soon as one of the three LED PIN assignments is not defined (commented out), the Example sketch will lock itself after initializing NRF radio, and running DHCP. So, no further NRF communication nor signup at the broker. WDT steps in then.

Just defining all three LEDs, without any other parameter or use the LED blinking feature, and everything is fine.