Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Announcements
  3. MySensors 1.4 Released

MySensors 1.4 Released

Scheduled Pinned Locked Moved Announcements
72 Posts 19 Posters 28.8k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M mikeones

    @hek

    It appears sending "255;255;3;0;4;1\r\n" fixes my issue.

    send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
    read: 0-0-255 s=255,c=3,t=4,pt=0,l=1:1
    id=1
    sensor started, id 1
    
    hekH Offline
    hekH Offline
    hek
    Admin
    wrote on last edited by
    #41

    @mikeones

    Ok thanks. I will make this more robust. It should be ok to skip the carriage return character.

    1 Reply Last reply
    0
    • M Offline
      M Offline
      mikeones
      wrote on last edited by mikeones
      #42

      What does st=fail represent? Is that stating the ack failed or sending failed? Would this error show up for all messages if debug is enabled on the sensor node and not the gateway.? Maybe this is a non issue? I am trying to confirm if gw.getConfig and gw.requestTime requests are reaching the GW since they don't seem to be set consistently in my environment.

      sensor started, id 3
      send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=3,st=fail:1.4
      send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,st=fail:0
      send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=8,st=ok:Humidity
      send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
      send: 3-3-0-0 s=0,c=0,t=7,pt=0,l=3,st=fail:1.4
      send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=3,st=fail:1.4
      send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,st=fail:25.8
      T: 25.80
      send: 3-3-0-0 s=0,c=1,t=1,pt=7,l=5,st=fail:50.4
      H: 50.40
      send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,st=fail:25.8
      T: 25.80
      send: 3-3-0-0 s=0,c=1,t=1,pt=7,l=5,st=fail:50.4
      H: 50.40
      
      1 Reply Last reply
      0
      • hekH hek

        ###1.4 update 1 released

        NOTE: This release does not require you to update all nodes . Nothing has changed in protocols.

        • All outgoing messages from gateway included a newline character. This has now been fixed.
        • The msg.getByte() wrongfully used atoi() conversion if payload was of string type.
        • The getByte-bug caused problems when receiving Metric/Imperial settings from controller.
        • A new sleep-method added to allow wake-up on both external interrupts.
        • A new example BinarySwitchSleepSensor showing the new sleep function (thanks @Anticimex).
        • Library code (RF24) reduced by 624 bytes (thanks @Damme)
        • Many people has reported powering problems when using amplified version of the NRF-chip on their gateway. The Arduino Nanos 3v3 output does not seem to be sufficient for PA_MAX. The radio needs to be feeded separately with a stable 3v3 to work. Defaulting gateway PA-level to LOW now and if you are using a vanilla radio on gateway you can switch back to MAX in your MyConfig.h.
        RJ_MakeR Offline
        RJ_MakeR Offline
        RJ_Make
        Hero Member
        wrote on last edited by
        #43

        @hek said:> ###1.4 update 1 released

        NOTE: This release does not require you to update all nodes . Nothing has changed in protocols.

        • All outgoing messages from gateway included a newline character. This has now been fixed.
        • The msg.getByte() wrongfully used atoi() conversion if payload was of string type.
        • The getByte-bug caused problems when receiving Metric/Imperial settings from controller.
        • A new sleep-method added to allow wake-up on both external interrupts.
        • A new example BinarySwitchSleepSensor showing the new sleep function (thanks @Anticimex).
        • Library code (RF24) reduced by 624 bytes (thanks @Damme)
        • Many people has reported powering problems when using amplified version of the NRF-chip on their gateway. The Arduino Nanos 3v3 output does not seem to be sufficient for PA_MAX. The radio needs to be feeded separately with a stable 3v3 to work. Defaulting gateway PA-level to LOW now and if you are using a vanilla radio on gateway you can switch back to MAX in your MyConfig.h.

        Was this release supposed to fix the C to F conversion problem I've been having? I just updated and problem persists for me.

        2014-09-08_12-28-44.png

        2014-09-08_12-29-11.png

        RJ_Make

        hekH 1 Reply Last reply
        0
        • RJ_MakeR RJ_Make

          @hek said:> ###1.4 update 1 released

          NOTE: This release does not require you to update all nodes . Nothing has changed in protocols.

          • All outgoing messages from gateway included a newline character. This has now been fixed.
          • The msg.getByte() wrongfully used atoi() conversion if payload was of string type.
          • The getByte-bug caused problems when receiving Metric/Imperial settings from controller.
          • A new sleep-method added to allow wake-up on both external interrupts.
          • A new example BinarySwitchSleepSensor showing the new sleep function (thanks @Anticimex).
          • Library code (RF24) reduced by 624 bytes (thanks @Damme)
          • Many people has reported powering problems when using amplified version of the NRF-chip on their gateway. The Arduino Nanos 3v3 output does not seem to be sufficient for PA_MAX. The radio needs to be feeded separately with a stable 3v3 to work. Defaulting gateway PA-level to LOW now and if you are using a vanilla radio on gateway you can switch back to MAX in your MyConfig.h.

          Was this release supposed to fix the C to F conversion problem I've been having? I just updated and problem persists for me.

          2014-09-08_12-28-44.png

          2014-09-08_12-29-11.png

          hekH Offline
          hekH Offline
          hek
          Admin
          wrote on last edited by
          #44

          @ServiceXp
          Think I found the config problem. No wonder it didn't work. Please download and try again.

          @mikeones
          You should now be able to omit carriage return now.
          The fail you're seeing is for the inter-node-ack.
          Just verified requesting time from controller and it seems to work fine here (using the example sketch).

          RJ_MakeR 1 Reply Last reply
          0
          • YveauxY Offline
            YveauxY Offline
            Yveaux
            Mod
            wrote on last edited by
            #45

            @hek When MySensors has no parent, or fails to contact parent for a number of times, the findParentNode() method is entered.
            This sends a broadcast (ignoring the result) and then waits at most 2 seconds for a response.
            When this response doesn't come, the sensor just carries on as if the parent has been found, sending messages until again a number of times it failed to contact the parent.

            Shouldn't findParentNode() either block until the parent has been found (maybe not desirable for battery based nodes) or only reset the failedTransmissions counter when a succesful response from the parent has been received?

            http://yveaux.blogspot.nl

            hekH 1 Reply Last reply
            0
            • YveauxY Yveaux

              @hek When MySensors has no parent, or fails to contact parent for a number of times, the findParentNode() method is entered.
              This sends a broadcast (ignoring the result) and then waits at most 2 seconds for a response.
              When this response doesn't come, the sensor just carries on as if the parent has been found, sending messages until again a number of times it failed to contact the parent.

              Shouldn't findParentNode() either block until the parent has been found (maybe not desirable for battery based nodes) or only reset the failedTransmissions counter when a succesful response from the parent has been received?

              hekH Offline
              hekH Offline
              hek
              Admin
              wrote on last edited by
              #46

              @Yveaux said:

              Shouldn't findParentNode() either block until the parent has been found (maybe not desirable for battery based nodes) or only reset the failedTransmissions counter when a succesful response from the parent has been received?

              Blocking is as you say a bad idea for battery sensors (1.3 had this problem resulting in drained batteries).

              How would it help to reset failedTransmissions?

              YveauxY 1 Reply Last reply
              0
              • hekH Offline
                hekH Offline
                hek
                Admin
                wrote on last edited by
                #47

                @Yveaux

                BTW. Do you have any idea why this happens?

                http://forum.mysensors.org/topic/347/1-4-error-compiling-with-pinchangeint-h-library-file/5

                I can't explain why linker includes things from MyGateway.cpp when compiling sensor examples.

                YveauxY 1 Reply Last reply
                0
                • hekH hek

                  @Yveaux said:

                  Shouldn't findParentNode() either block until the parent has been found (maybe not desirable for battery based nodes) or only reset the failedTransmissions counter when a succesful response from the parent has been received?

                  Blocking is as you say a bad idea for battery sensors (1.3 had this problem resulting in drained batteries).

                  How would it help to reset failedTransmissions?

                  YveauxY Offline
                  YveauxY Offline
                  Yveaux
                  Mod
                  wrote on last edited by
                  #48

                  @hek said:

                  How would it help to reset failedTransmissions?

                  Just thinking out aloud:

                  • Don't reset failedTransmissions in findParentNode()
                  • Reset failedTransmissions only when a new parent has been found
                  • In sendRoute() first perform findParentNode() when failedTransmissions > SEARCH_FAILURES
                  • When succesful (failedTransmissions == 0) perform sendWrite()

                  This will always first try to find a parent when none has been found yet, before trying to send the message.
                  If it fails, the send of the message will fail and the (battery powered) sensor will just carry on as if the message has been send, and sleep the sensor as usual.
                  Just sending to a known-bad parent node should be avoided at all times.

                  http://yveaux.blogspot.nl

                  hekH 1 Reply Last reply
                  0
                  • YveauxY Yveaux

                    @hek said:

                    How would it help to reset failedTransmissions?

                    Just thinking out aloud:

                    • Don't reset failedTransmissions in findParentNode()
                    • Reset failedTransmissions only when a new parent has been found
                    • In sendRoute() first perform findParentNode() when failedTransmissions > SEARCH_FAILURES
                    • When succesful (failedTransmissions == 0) perform sendWrite()

                    This will always first try to find a parent when none has been found yet, before trying to send the message.
                    If it fails, the send of the message will fail and the (battery powered) sensor will just carry on as if the message has been send, and sleep the sensor as usual.
                    Just sending to a known-bad parent node should be avoided at all times.

                    hekH Offline
                    hekH Offline
                    hek
                    Admin
                    wrote on last edited by
                    #49

                    @Yveaux

                    Sounds good. Go for it!

                    YveauxY 2 Replies Last reply
                    0
                    • hekH hek

                      @Yveaux

                      Sounds good. Go for it!

                      YveauxY Offline
                      YveauxY Offline
                      Yveaux
                      Mod
                      wrote on last edited by
                      #50

                      @hek ;-)

                      http://yveaux.blogspot.nl

                      1 Reply Last reply
                      0
                      • hekH hek

                        @Yveaux

                        BTW. Do you have any idea why this happens?

                        http://forum.mysensors.org/topic/347/1-4-error-compiling-with-pinchangeint-h-library-file/5

                        I can't explain why linker includes things from MyGateway.cpp when compiling sensor examples.

                        YveauxY Offline
                        YveauxY Offline
                        Yveaux
                        Mod
                        wrote on last edited by
                        #51

                        @hek said:

                        I can't explain why linker includes things from MyGateway.cpp when compiling sensor examples.

                        Compiler & linker seem to be configured correctly in 1.5.7 (see hardware\arduino\avr\patform.txt)
                        Did you have a look at the map-file? What exactly is included from the MyGateway.cpp file?

                        http://yveaux.blogspot.nl

                        hekH 1 Reply Last reply
                        0
                        • hekH hek

                          @Yveaux

                          Sounds good. Go for it!

                          YveauxY Offline
                          YveauxY Offline
                          Yveaux
                          Mod
                          wrote on last edited by Yveaux
                          #52

                          @hek I'm also a bit puzzled by the RF24::enableAckPayload() and RF24::writeAckPayload() calls in the library, just like @Zeph .
                          If I disable them the findParentNode() call only seems to emit a single message (which I can understand, as auto-ack is disabled for broadcasts), while 16 will be emit when the calls are enabled.
                          Looks like auto-ack doesn't get disabled for broadcasts in this case.

                          A sending nRF24 will immediately & automatically **switch to listen to the destination node's ID **after it has sent its message. Reason for this is that the nRF24 packet format only contains a destination node address and no source. The receiving node has no idea where the message came from and does not know who to send the ack to. Therefore it just sends the ack to its own node address, which the transmitting node happens to listen to.

                          I tested only with a single sensor sending to a non-existent parent, but I can imagine that when auto-acks are enabled for broadcasts the s**t will definately hit the fan when there are many nodes within close proximity!

                          http://yveaux.blogspot.nl

                          hekH 1 Reply Last reply
                          0
                          • YveauxY Yveaux

                            @hek said:

                            I can't explain why linker includes things from MyGateway.cpp when compiling sensor examples.

                            Compiler & linker seem to be configured correctly in 1.5.7 (see hardware\arduino\avr\patform.txt)
                            Did you have a look at the map-file? What exactly is included from the MyGateway.cpp file?

                            hekH Offline
                            hekH Offline
                            hek
                            Admin
                            wrote on last edited by
                            #53

                            @Yveaux

                            Ok, I'll download 1.5.7 and test again. Can't find any map-file anywhere in the build directory.

                            YveauxY 1 Reply Last reply
                            0
                            • hekH hek

                              @Yveaux

                              Ok, I'll download 1.5.7 and test again. Can't find any map-file anywhere in the build directory.

                              YveauxY Offline
                              YveauxY Offline
                              Yveaux
                              Mod
                              wrote on last edited by
                              #54

                              @hek said:

                              Can't find any map-file anywhere in the build directory.

                              I think Arduino does not enable it by default. You either have to add generation to the build-parameters in platform.txt, or generate it afterwards .

                              http://yveaux.blogspot.nl

                              1 Reply Last reply
                              0
                              • YveauxY Yveaux

                                @hek I'm also a bit puzzled by the RF24::enableAckPayload() and RF24::writeAckPayload() calls in the library, just like @Zeph .
                                If I disable them the findParentNode() call only seems to emit a single message (which I can understand, as auto-ack is disabled for broadcasts), while 16 will be emit when the calls are enabled.
                                Looks like auto-ack doesn't get disabled for broadcasts in this case.

                                A sending nRF24 will immediately & automatically **switch to listen to the destination node's ID **after it has sent its message. Reason for this is that the nRF24 packet format only contains a destination node address and no source. The receiving node has no idea where the message came from and does not know who to send the ack to. Therefore it just sends the ack to its own node address, which the transmitting node happens to listen to.

                                I tested only with a single sensor sending to a non-existent parent, but I can imagine that when auto-acks are enabled for broadcasts the s**t will definately hit the fan when there are many nodes within close proximity!

                                hekH Offline
                                hekH Offline
                                hek
                                Admin
                                wrote on last edited by
                                #55

                                @Yveaux said:

                                If I disable them the findParentNode() call only seems to emit a single message (which I can understand, as auto-ack is disabled for broadcasts), while 16 will be emit when the calls are enabled.
                                Looks like auto-ack doesn't get disabled for broadcasts in this case.

                                Ok, 16! Hmm..not good.
                                Could you perhaps do some more verifications with removed ackPayload/writeAckPayload while sniffing to see that everything works as expected with the whole findParent?
                                Would be a nice addition to get this removed while you refactor findParent.

                                YveauxY 1 Reply Last reply
                                0
                                • hekH hek

                                  @Yveaux said:

                                  If I disable them the findParentNode() call only seems to emit a single message (which I can understand, as auto-ack is disabled for broadcasts), while 16 will be emit when the calls are enabled.
                                  Looks like auto-ack doesn't get disabled for broadcasts in this case.

                                  Ok, 16! Hmm..not good.
                                  Could you perhaps do some more verifications with removed ackPayload/writeAckPayload while sniffing to see that everything works as expected with the whole findParent?
                                  Would be a nice addition to get this removed while you refactor findParent.

                                  YveauxY Offline
                                  YveauxY Offline
                                  Yveaux
                                  Mod
                                  wrote on last edited by
                                  #56

                                  @hek first need to rebuild the mysensors setup. Everything is Radiohead now....

                                  http://yveaux.blogspot.nl

                                  hekH 1 Reply Last reply
                                  0
                                  • YveauxY Yveaux

                                    @hek first need to rebuild the mysensors setup. Everything is Radiohead now....

                                    hekH Offline
                                    hekH Offline
                                    hek
                                    Admin
                                    wrote on last edited by
                                    #57

                                    @Yveaux said:

                                    Everything is Radiohead now

                                    :O

                                    You sniffing is really helpful finding bugs and quirks in the radios bwt!

                                    YveauxY 1 Reply Last reply
                                    0
                                    • hekH hek

                                      @Yveaux said:

                                      Everything is Radiohead now

                                      :O

                                      You sniffing is really helpful finding bugs and quirks in the radios bwt!

                                      YveauxY Offline
                                      YveauxY Offline
                                      Yveaux
                                      Mod
                                      wrote on last edited by
                                      #58

                                      @hek yeah I know. I can't think of developing any networking stack without knowing what's really going on...
                                      Why don't you build one yourself ? ;-)

                                      http://yveaux.blogspot.nl

                                      hekH 1 Reply Last reply
                                      0
                                      • YveauxY Yveaux

                                        @hek yeah I know. I can't think of developing any networking stack without knowing what's really going on...
                                        Why don't you build one yourself ? ;-)

                                        hekH Offline
                                        hekH Offline
                                        hek
                                        Admin
                                        wrote on last edited by
                                        #59

                                        @Yveaux

                                        I would really love to, but unfortunately I don't have any computer to lobotomize with windos.

                                        YveauxY 1 Reply Last reply
                                        0
                                        • hekH hek

                                          @Yveaux

                                          I would really love to, but unfortunately I don't have any computer to lobotomize with windos.

                                          YveauxY Offline
                                          YveauxY Offline
                                          Yveaux
                                          Mod
                                          wrote on last edited by
                                          #60

                                          @hek maybe run it in a virtual machine?
                                          I should have written the serial-wireshark bridge in a more portable way...

                                          http://yveaux.blogspot.nl

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          13

                                          Online

                                          11.7k

                                          Users

                                          11.2k

                                          Topics

                                          113.1k

                                          Posts


                                          Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • MySensors
                                          • OpenHardware.io
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular