Noob : Cant get Sensor talking to gateway



  • Hey all,

    This is my first Mysensors adventure and I cant seem to get things working..

    I have a trivially simple sketch, just to test its working but the arduino doesnt event get to my "loop".. Im baffled.. i think im doing something wrong software wise but... bafled.. Oh I know the arduino is on 2.1.1 and the Pi on 2.2.0-rc.1 but I cant work out how to burn the same version to the arduino....

    thanks in advance
    Angelo

    
    #include <SPI.h>
    #define MY_DEBUG
    #define CHILD_ID_TEMP 1
    #define MY_RADIO_NRF24
    #include <MyConfig.h>
    #include <MySensors.h>
    MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
    void presentation()  
    { 
      // Send the sketch version information to the gateway
      sendSketchInfo("AngelosTesting", "1.1");
      present(CHILD_ID_TEMP, S_TEMP);
    }
    
    void setup()
    {
      Serial.println("Init");  
    }
    void loop()      
    {  
      
        Serial.println("Sending data");
        send(msgTemp.set("42!"));
        sleep (5000);
    }
    

    However the sensor just says "fail",.. what is interesting that when the sensor says its failure message the gateway does receive something but.. the sensor doesnt like it..

    Arduino Mini Pro sensor

    0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
    4 TSM:INIT
    4 TSF:WUR:MS=0
    12 TSM:INIT:TSP OK
    14 TSM:FPAR
    16 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    2025 !TSM:FPAR:NO REPLY
    2027 TSM:FPAR
    2029 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    4038 !TSM:FPAR:NO REPLY
    4040 TSM:FPAR
    4042 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    4636 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
    4642 TSF:MSG:FPAR OK,ID=0,D=1
    6051 TSM:FPAR:OK
    6051 TSM:ID
    6053 TSM:ID:REQ
    6057 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
    8065 TSM:ID
    8065 TSM:ID:REQ
    8069 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
    10076 TSM:ID
    10076 TSM:ID:REQ
    10080 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
    12089 TSM:ID
    12089 TSM:ID:REQ
    12093 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
    14102 !TSM:ID:FAIL
    14104 TSM:FAIL:CNT=1
    14106 TSM:FAIL:PDT
    

    Raspberry Pi Gateway

    mysgw: Starting gateway...
    mysgw: Protocol version - 2.2.0-rc.1
    mysgw: MCO:BGN:INIT GW,CP=RNNGL---,VER=2.2.0-rc.1
    mysgw: TSF:LRT:OK
    mysgw: TSM:INIT
    mysgw: TSF:WUR:MS=0
    mysgw: TSM:INIT:TSP OK
    mysgw: TSM:INIT:GW MODE
    mysgw: TSM:READY:ID=0,PAR=0,DIS=0
    mysgw: MCO:REG:NOT NEEDED
    mysgw: Listening for connections on 0.0.0.0:5003
    mysgw: MCO:BGN:STP
    mysgw: MCO:BGN:INIT OK,TSP=1
    mysgw: TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    mysgw: TSF:MSG:BC
    mysgw: TSF:MSG:FPAR REQ,ID=255
    mysgw: TSF:CKU:OK,FCTRL
    mysgw: TSF:MSG:GWL OK
    mysgw: TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
    mysgw: TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
    mysgw: TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
    mysgw: TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
    mysgw: TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    mysgw: TSF:MSG:BC
    mysgw: TSF:MSG:FPAR REQ,ID=255
    mysgw: TSF:PNG:SEND,TO=0
    mysgw: TSF:CKU:OK
    mysgw: TSF:MSG:GWL OK
    mysgw: TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
    mysgw: TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
    

  • Mod

    You need to assign a node ID on your sensor node



  • @Angelo-Santagata the log parser is useful in these situations.

    https://www.mysensors.org/build/parserlink text

    In your case, it calls my attention that the gw seems to be answering the requests for an ID from the node with an empty payload. I would start the investigation here.

    For a check, assign an static node Id to the node and try see what happens.



  • thanks for the pointer guys, I'll check this out when I get home..



  • If you have used this same sensors as a test in the past you may need to clear the eeprom data also.

    Just a guess...



  • @manutremo thanks, I have used the parselink text utility but I should have paid more attention
    mm Ive used the same hardware but never got it working. .. your right maybe its stored a dud nodeID.. Looking at the docs https://www.mysensors.org/download/sensor_api_20 I can set a nodeID manually.. I'll give that a go





  • @r-nox AWESOME! thank you!

    Nice to see this OS library is well supported... cool



  • @manutremo , you hit it bang on.. The NODE_ID wasnt being sent, setting a node id to a number using
    #define MY_NODE_ID 42
    worked.

    Curious, so I can debug this myself in the future, which line indicated the NODE_ID was blank?
    was it this line?
    mysgw: TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:



  • @Angelo-Santagata happy to know that you got it working. Yes I think that's the line which in the log parser showed an empty payload. It would be interesting to know why the gw is returning an empty payload when an ID is requested, though, since that's not usual behavior with the default settings. Let us know what you find out!


  • Mod

    If there is no controller assigning an ID, the gw can't make up one out of nothing. 😀



  • That's certainly the most probable cause, Angelo didn't mention any controller so I assumed there is one... which controller are you using (if any) Angelo?


  • Mod

    There could be a controller but if it is not assigning any ID is it just as it wasn't any 😁



  • Yes, the fact that it works with a static node id seems to point in that direction - should that not be the case, i sincerely wouldn't have a clue on where to look at.



  • Hi all,

    ok this is the embarrassing bit, no the controller wasnt attached.. Im using home assistant and what I didnt realise that was that a) the controller sends the IDs and b) the controller couldnt talk to the Gateway..

    BTW Why do we need a controller to assign the unique sensor IDs? I thought the Gateway would do this?


  • Mod

    @Angelo-Santagata the gateways are designed to be stateless. The stateless design makes it easy to implement a gateway on low-power hardware. It also makes it easier to correctly implement and verify the gateway functionality, and to troubleshoot if there are problems. If gateways had to remember which ids had been assigned, they would no longer be stateless.



  • @mfalkvidd thanks, very impressive this mySensors stuff BTW


  • Mod

    @angeloS thanks. I agree. I can't take credit for it though, most of the stuff was designed before I found the project 🙂



  • Mistery solved 😆


  • Mod

    Does anyone have suggestions on a clearer log message? One that would make it easy to understand what is happening? If we could make the log clearer, other people could understand the reason quicker, saving time and frustration.



  • @mfalkvidd In my case I think if the log had said, No Controller provided SensorID, that would have been my first clue



  • @angeloS Fully agree - a warning instead of just sending a message with an empty payload would have been easier to spot. Maybe something to propose in Github?


  • Mod

    @manutremo which message are you referring to?


  • Mod

    We could add a sample message, in the troubleshooting guide, when the node has no Node ID and the gateway is responding an empty message, so a Node ID must be defined in the sketch



  • @mfalkvidd Without being an specialist in the MySensors protocol, it could be something like

    • a debug message at some point in the gateway log when a node ID is requested and there is no ID to provide (no controller available),

    • something similar in the node log when an empty ID is provided form the gw

    • additionally, a warning in the log parser to check the controller when the payload is empty.


  • Mod

    @gohan and @manutremo when does the gateway respond with an empty message? I am not able to find that in the logs posted earlier in this thread.



  • @mfalkvidd Just reviewed the gw log and you're right, the gw just doesn't answer... I guess in this case it's just not possible to separate the cases when the gateway doesn't have a controller, or is off, or communication didn't arrive, or... in all cases, the node seems to end up with a ID=255.

    As I said, not familiar with the protocol...


  • Mod

    @manutremo the gateway is just a dumb forwarder. When the ID request is received from the sensor node, the gateway forwards that message to it's configured interface (mqtt, ethernet, serial, ...). If the controller responds, the gateway will forward the response.

    To do your suggested no 1, the gateway would have to keep track of all ID requests and set some time to know when the response from the controller is deemed too slow. That could probably be done, but would require quite a lot of work to get right and to keep compact enough to still fit the gateway in popular constrained devices like the atmega328.

    The message in no 2 doesn't exist, as we have agreed on, so this is unfortunately not viable either.

    Your suggestion no 3 sounds promising I think. Whenever the node prints !TSM:ID:FAIL, the log parser should spell out that the most likely cause is that no controller is present. I'm not sure how to update the log parser, but maybe @hek can chip in here? At the moment, the log parser seems unable to parse that message at all.

    https://www.mysensors.org/apidocs/group__MyTransportgrp.html#details should be updated to mention the controller on the line where TSM ID FAIL is mentioned.

    It would also be nice if the !TSM:ID:FAIL message was more verbose (for people who don't immediately use the log parser), but the log messages need to be kept very short to keep the binary size small.


  • Mod

    A suggestion for updating the documentation is available at https://github.com/mysensors/MySensors/pull/984
    Feedback is welcome.


  • Mod



  • I have been facing the same problem all day today. Actually as far as I remember my old nodes used to setup the node assignation to AUTO by default.

    Was that changed during the last month ? because I was busy at that period.


  • Mod

    @ahmedadelhosni auto id has been default since inception, as far as I know. It was default 2.5 years ago when I first learned about MySensors. So nothing has changed.


  • Mod

    It defaults to Auto if no manual define is set, but it still needs a controller or just myscontroller application that keeps track of the IDs and assign new unused ones.



  • @mfalkvidd That's what I know but as I have said, I have been facing the same error to assign an ID for my node and it was solved when I change it to static ID... strange !



  • i was thinking about this, perhaps as part of a welcome tutorial we connect the GW to a gateway (pick one , an easy one). And whilst doing this we simply explain why the Controller is needed.. this would help newbies like me from the start..

    Which controller.. well Ive been looking at openhab but settled on Homeassistant, appears more active that OH

    Angelo


  • Mod

    @angeloS do you mean to add information to this page? https://www.mysensors.org/build/select_gateway

    The getting started guide already mentions (twice actually) that the controller is responsible for handling automatic node id assignment.

    If people don't read the getting started guide, will they really read the Select gateway page?



  • I have the same situation - mysensors relay node can not find parent. I cleared eeprom and entered manually MY_NODE_ID, but it seems that gateway and node communicate, but fail to make final arrengement.

    Gateway log:
    22:54:33.173 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;Will not sign message for destination 102 as it does not require it
    22:54:33.216 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;!TSF:MSG:SEND,0-0-102-102,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
    22:54:34.691 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:READ,102-102-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    22:54:34.692 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:BC
    22:54:34.694 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=102
    22:54:34.697 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:CKU:OK,FCTRL
    22:54:34.701 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:GWL OK

    MySensors node log:
    91296 TSM:INIT
    791303 TSM:INIT:TSP OK
    791305 TSM:INIT:STATID=102
    791308 TSF:SID:OK,ID=102
    791310 TSM:FPAR
    791347 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    793354 !TSM:FPAR:NO REPLY
    793356 TSM:FPAR
    793393 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    795400 !TSM:FPAR:NO REPLY
    795402 TSM:FPAR
    795439 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    797446 !TSM:FPAR:NO REPLY
    797448 TSM:FPAR
    797485 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    799492 !TSM:FPAR:FAIL
    799494 TSM:FAIL:CNT=7
    799496 TSM:FAIL:PDT
    859499 TSM:FAIL:RE-INIT
    859501 TSM:INIT
    859508 TSM:INIT:TSP OK
    859510 TSM:INIT:STATID=102
    859513 TSF:SID:OK,ID=102
    859515 TSM:FPAR
    859552 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    861559 !TSM:FPAR:NO REPLY
    861561 TSM:FPAR
    861598 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    863605 !TSM:FPAR:NO REPLY
    863607 TSM:FPAR
    863644 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    865651 !TSM:FPAR:NO REPLY
    865653 TSM:FPAR
    865690 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    867697 !TSM:FPAR:FAIL
    867699 TSM:FAIL:CNT=7
    867701 TSM:FAIL:PDT

    any ideas what I have to check?

    regards,

    rimantas


  • Mod

    There is a problem with messages sent by gateway or received by node: you either have bad power supply for radio on gateway or bad antenna or antenna alignment or too much distance; could also be interference near the node


Log in to reply
 

Suggested Topics

10
Online

11.4k
Users

11.1k
Topics

112.7k
Posts