Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Erik Forsberg
    3. Topics
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Topics created by Erik Forsberg

    • Erik Forsberg

      (Relay) node asks for parent. Gateway forwards (!)
      Troubleshooting • • Erik Forsberg  

      6
      0
      Votes
      6
      Posts
      1098
      Views

      Erik Forsberg

      Hmm.. basically, this node works if signing is disabled. If it's enabled, all the nonce requests fail to transmit (with st=NACK). Disabling signing, it has greater success in transferring its data. So I guess it's yet another problem with the radio. I suspected this. This is an NRF24L01+PA+LNA module. I have: Tried multiple radio modules to rule out a faulty one. Put the radio module on a dedicated 3.3V power regulator. Tried both high and low PA level. Same thing on gateway - NRF24L01+PA+LNA, on dedicated 3.3V power regulator. It seems to succeed in most cases, at least when it's sending just a set request. Presentations and others do not work. It's like it's having trouble transmitting longer messages. Odd. The code in this sketch is using an interrupt handler to count pulsess on my energy meter. Could this be related? Some debug output from the node, with signing disabled: MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.0.1-beta TSM:INIT TSM:INIT:TSP OK TSF:ASID:OK,ID=4 TSM:FPAR TSF:MSG:SEND,4-4-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc: TSF:MSG:READ,0-0-4,s=255,c=3,t=8,pt=1,l=1,sg=0:0 TSF:MSG:FPAR RES,ID=0,D=0 TSF:MSG:FPAR OK,ID=0,D=1 TSM:FPAR:OK TSM:ID TSM:ID:OK,ID=4 TSM:UPL TSF:PING:SEND,TO=0 TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1 TSF:MSG:READ,0-0-4,s=255,c=3,t=25,pt=1,l=1,sg=0:1 TSF:MSG:PONG RECV,HP=1 TSF:CHKUPL:OK TSM:UPL:OK TSM:READY TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100 !TSF:MSG:SEND,4-4-0-0,s=255,c=0,t=18,pt=0,l=10,sg=0,ft=0,st=NACK:2.0.1-beta TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=1,st=OK:0 TSF:MSG:READ,0-0-4,s=255,c=3,t=15,pt=6,l=2,sg=0:0100 TSF:MSG:READ,0-0-4,s=255,c=3,t=6,pt=0,l=1,sg=0:M !TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=NACK:Energy Meter TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=1,st=OK:1.1 TSF:MSG:SEND,4-4-0-0,s=4,c=0,t=13,pt=0,l=0,sg=0,ft=0,st=OK: MCO:REG:REQ TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2 TSF:MSG:READ,0-0-4,s=255,c=3,t=27,pt=1,l=1,sg=0:1 MCO:PIM:NODE REG=1 setup(). Radio Channel is 42 TSF:MSG:SEND,4-4-0-0,s=4,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK: MCO:BGN:INIT OK,ID=4,PAR=0,DIS=1,REG=1 TSF:MSG:READ,0-0-4,s=4,c=1,t=24,pt=0,l=7,sg=0:7418044 Received last pulse count from gw:7418044 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=17,pt=5,l=4,sg=0,ft=0,st=OK:3169 Watt:3169 !TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=24,pt=5,l=4,sg=0,ft=0,st=NACK:7418088 !TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=18,pt=7,l=5,sg=0,ft=1,st=NACK:741.8089 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=17,pt=5,l=4,sg=0,ft=2,st=OK:3156 Watt:3156 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=24,pt=5,l=4,sg=0,ft=0,st=OK:7418132 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=18,pt=7,l=5,sg=0,ft=0,st=OK:741.8133 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=17,pt=5,l=4,sg=0,ft=0,st=OK:3169 Watt:3169 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=24,pt=5,l=4,sg=0,ft=0,st=OK:7418177 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=18,pt=7,l=5,sg=0,ft=0,st=OK:741.8177 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=17,pt=5,l=4,sg=0,ft=0,st=OK:7311 Watt:7241 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=24,pt=5,l=4,sg=0,ft=0,st=OK:7418249 TSF:MSG:SEND,4-4-0-0,s=4,c=1,t=18,pt=7,l=5,sg=0,ft=0,st=OK:741.8249```
    • Erik Forsberg

      2.0 beta, compatible with 1.5?
      Development • • Erik Forsberg  

      7
      1
      Votes
      7
      Posts
      2883
      Views

      cdr

      @rollercontainer correct
    • Erik Forsberg

      Expected reply from Controller if requesting a variable that does not exist?
      General Discussion • • Erik Forsberg  

      6
      0
      Votes
      6
      Posts
      1510
      Views

      martinhjelmare

      @Erik-Forsberg I think one should be a bit careful about making too many special rules for different cases, between device and controller. I think there should be set ways of communicating between the controller and device. There should also be ways for the user to make rules to create the automations, but this should not change the set ways for communication. In this case, when we need an initial value from the user, which should be automated somehow, I think the user should be able to make rules, and somehow be able to set an initial state, by controller API or other means. But I think that should be detached from the specific device - controller communication. You can have a look at my handle_req branch here: https://github.com/MartinHjelmare/pymysensors/tree/handle_req I would say your implementation looks fine, although I have some comments. We can continue at github.
    • Erik Forsberg

      What does the LED blinking (pin 13) mean?
      General Discussion • • Erik Forsberg  

      7
      0
      Votes
      7
      Posts
      6136
      Views

      georgep56

      @TimO To confirm this I just 'rebuilt' my actuator node as the example humidity sensor (swapped a few links on my breadboard) and now the Pin13 LED behaves just like the other sensor node, mostly off with just a tiny flicker on each transmit.