MySensors 1.4 Released
-
Great work, Henrik!
And good work on fostering a community of cats as well!
Donation made in honor of the release.
-
-
@hek congratulations indeed
nice surprise looking at the forum after a 10 hour drive back home...
-
Congratulations!!
-
@ServiceXp said:
Indeed!! Thank you everyone for all the hard work that goes into this project to help make it all possible for those of us like me who don't really have a clue what we are doing.
I gotta agree with this big time!
The examples and the ease in which I can upload sketches is great, and because it is so easy i have the confidence to do this and try different things and learn. It has been over 20 years since I programmed any code, and that length of time has kind of scared me so I felt I couldn't do it again, but this is just made so easy!
I love the pics and I just watched the video demo on the knock sensor! That was awesome!!!!
-
@hek Congratulations to you and to everyone involved in making this transition. Thanks for everything you have done for us.
Is it safe to assume that all of the code examples are now Lib 1.4 based? As I recall previous discussion said the Lib 1.4 change has to be applied to the Gateway and Sensors all together?
-
Awesome! Thanks for great work!
-
@clippermiami said:
Is it safe to assume that all of the code examples are now Lib 1.4 based? As I recall previous discussion said the Lib 1.4 change has to be applied to the Gateway and Sensors all together?
Yes, everything on main site is now 1.4.
-
Hello,
I am a bit puzzled by the documentation online as I try to upgrade my home made controller/gateway.
Before we had a description of the radio signal as 5 fields, now it is 6 and even reading the lua code for Vera I've not seen the new field being used. (apart for making it not backward compatible, not a big issue for me)
Also some new capacities are here, but they lack documentation (at least for me), where can I have a look to see the expected behavior on both side ? (sensor and controller/gateway)?
And to finish, what is the ack behavior on the radio, meaning that before I observed that the sendVariable needed to be requested 2 to 3 times to have it correctly received by the node, is there an automatic retry from the node as before ? (I suspect not from the simpler and clever new method...).
As a positive note, I've moved all my sketches to 1.4 (time bounced watermeter was the hardest) and run a parallel gateway till all is "stable", so far so good !
-
@epierre said:
Before we had a description of the radio signal as 5 fields, now it is 6 and even reading the lua code for Vera I've not seen the new field being used. (apart for making it not backward compatible, not a big issue for me)
No, the (incoming) ack status is currently not used by the Vera plugin. For outgoing messages to actuators it is always enabled.
Also some new capacities are here, but they lack documentation (at least for me), where can I have a look to see the expected behavior on both side ? (sensor and controller/gateway)?
Yes, agree. This could be documented better.
And to finish, what is the ack behavior on the radio, meaning that before I observed that the sendVariable needed to be requested 2 to 3 times to have it correctly received by the node, is there an automatic retry from the node as before ? (I suspect not from the simpler and clever new method...).
No, the (blocking) automatic retry has been removed. If I would need retry functionality it would probably look something like this:
-
@hek sorry, I've editied the post, the android template makes me write like a blind man...
@hek said:
No, the (incoming) ack status is currently not used by the Vera plugin. For outgoing messages to actuators it is always enabled.
except for INTERNAL as it seems, is there a reason ?
Also some new capacities are here, but they lack documentation (at least for me), where can I have a look to see the expected behavior on both side ? (sensor and controller/gateway)?
Yes, agree. This could be documented better.
In the Vera LUA I only see TIME as a new event, right ?
And to finish, what is the ack behavior on the radio, meaning that before I observed that the sendVariable needed to be requested 2 to 3 times to have it correctly received by the node, is there an automatic retry from the node as before ? (I suspect not from the simpler and clever new method...).
No, the (blocking) automatic retry has been removed. If I would need retry functionality it would probably look something like this:
given the limited write cycle, I guess I wouldn't want to use the EEPROM for storing states. But if my watermeter starts but cannot get the reference volume, that would mean a mess if that persist, could the sensor loop on startup to get the data, but anyway manage reading the status of the sensor ?
-
@epierre said:
except for INTERNAL as it seems.
Yes, true.
In the LA I only see time as new, right ?
could the sensor soop on startup to get the data, but anyway manage reading the status of the sensor ?
-
Should I upgrade to the final..... currently using (1.4b1 (18848a2))? If so what is the proper way of doing so?
-
@ServiceXp
It depends on when you last updated. There hasn't been any radical library improvements the last few weeks. Just more examples.
Just download the latest and re-build/upload to sensors and gateway.
-
@hek
Will do, Thanks
-
@hek I corrected the post above... still the android template problem when posting...
-
@epierre said:
In the Vera LUA I only see TIME as a new event, right ?
TIME was present already in 1.3 (https://github.com/mysensors/Vera/compare/1.3...master)
given the limited write cycle, I guess I wouldn't want to use the EEPROM for storing states. But if my watermeter starts but cannot get the reference volume, that would mean a mess if that persist, could the sensor loop on startup to get the data, but anyway manage reading the status of the sensor ?
Guess you could implement it with some inspiration from my example above where you instead keep requesting watermeter level until you get a response. Meanwhile you can save watermeter values and add it to the grand total when response comes in.
-
@hek In what case should I use the ack ?
-
If you really want to make sure your sensor data has reached the gateway (or the other way around).
In the vera plugin the state isn't changed until ack comes back from actuator. So user get instant feedback if there is some problem in communication (=nothing updates in GUI).
-
Congratulations
-
###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.
-
This post is deleted!
-
@hek I am having an issue assigning a node ID since the last update. I have cleared the eprom in one of my nodes and I am trying to assign a node id of 1 via the serial monitor on the GW. I am sending "255;255;3;0;4;1" in response to the node ID request of "255;255;3;0;3;".
This is the console log from the node with debug enabled.
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,st=fail: read: 0-0-255 s=255,c=3,t=8,pt=1,l=1:0 new parent=0, d=1 req node id send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok: read: 0-0-255 s=255,c=3,t=4,pt=0,l=1:1 id=49 sensor started, id 49 send: 49-49-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4 send: 49-49-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0Here is the console log from the GW.
0;0;3;0;14;Gateway startup complete. 255;255;3;0;3; 49;255;0;0;17;1.4 49;255;3;0;6;0What I don't understand is why the node would get assigned ID "49" when I sent "1" as the new node ID. Should the node get an ID of "1" or "49" for the command below?
255;255;3;0;4;1
-
Darn, yes, you are so right. The getByte fix affected the node-id functionality. Please update again (MySensor.cpp) and report back.
-
@hek After updating, I have tested this via the serial monitor and it seems ok.
send: 255-255-0-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=1When I send this string via a (ago) controller, the node sets an id of 0 again. Do you see any issue with this string format?
255;255;3;0;4;1Serial monitor output. Does "l=0:" indicate there was an issue with the payload?
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=0: id=0
-
Hmm. I wonder which control characters Argcontrol sends ( \n and/or \r ). It could be that Vera sends both. I'll have to check when I get home.
-
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
-
Ok thanks. I will make this more robust. It should be ok to skip the carriage return character.
-
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
-
@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.
-
@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).
-
@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?
-
@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?
-
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.
-
@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.
-
Sounds good. Go for it!
-
-
@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?
-
@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!
-
Ok, I'll download 1.5.7 and test again. Can't find any map-file anywhere in the build directory.
-
@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 .
-
@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.
-
@hek first need to rebuild the mysensors setup. Everything is Radiohead now....
-
@Yveaux said:
Everything is Radiohead now
You sniffing is really helpful finding bugs and quirks in the radios bwt!
-
@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 ?
-
I would really love to, but unfortunately I don't have any computer to lobotomize with windos.
-
@hek maybe run it in a virtual machine?
I should have written the serial-wireshark bridge in a more portable way...
-
@hek said:> @ServiceXp
Think I found the config problem. No wonder it didn't work. Please download and try again.
Updated, and now it works! Thanks!!
-
I spoke too soon...
I'm going crazy trying to find out why my sensors with DS18B20 keep locking up.... Today I had to clear and re-upload a sketch to a locked up sensor and it would not convert to F.. Severals hours later, still would not convert..
-
@ServiceXp
You could test some other ds18b20 library and add a capacitor on the powerline to the temp-sensors.
-
@hek said:> @ServiceXp
You could test some other ds18b20 library and add a capacitor on the powerline to the temp-sensors.
I now believe it's related to the DS18D20 sensor. The same sensor locked up again when I got home, and interestingly enough they locked up @ -7.0 F. both times.
- I power cycled sensor, (Still Locked Up)
- Pushed sensor reset button. (Still Locked Up)
- I removed from freezer, warmed sensor; power cycled sensor again (Still Locked Up)
- Disconnected the DS18D20 from sensor and what do you know I was able to get it to recover.
So either this is just a freak of coincidence or the DS18D20 is some how locking up the Arduino in my environment. I installed a .47uF cap between the sensors VCC and GND wires, so we shall see.
Here is the serial output of the sensor:
-
Locked up again this morning @ 7:37am with a temp of -0.1. So a .47uF cap isn't the answer....
-
@hek Can you help me to understand how to get the update, and what parts are updated? I followed the download link to the library and installed the files. I then updated my gateway but I didn't see any version number change and I'm still having trouble with temperature readings coming through in Imperial units rather than metric.
Thanks, and keep up the great work!
Troy.
-
You followed the download link for 1.4 on the main site?
-
@hek said:
You followed the download link for 1.4 on the main site?
Hi Hek,
Yeah from the main page, I went to the Download page and then hit the Download button under the 1.4 Latest Release section. The readme file in the archive says 1.4, but I'm looking for 1.4 Update 1 which has the fixes for the imperial vs. metric units with temperature sensors. I rebuilt my gateway with the code anyway but no change. Am I missing something?
Thanks,
Troy.
-
Then you're using the latest 1.4 version.
You'll have to look at the debug prints on the sensor to see what is happening and determine if there's communication problem. I suspect that your sensors messages can reach the gateway but not the other way around (sometimes).
-
@hek I did some testing and it appeared to be a sync issue. First I looked at the gateway and the debug messages showed Imperial units which matched the Vera UI. Then I unplugged the temp. sensor from power and plugged it into my laptop and it was reporting Metric units in the debug, and then Vera started showing Metric. So I unplugged the sensor from my laptop, plugged it back into it's original location and the units switched back to Imperial. Finally I just rebooted the gateway and the sensor and now Metric is working.
Anyway, thanks for your help!
T.
-
@TroyF I've noticed that plugging/unplugging a sensor quite often changes the units between Metric and Imperial. Wonder why?
-
Just wondering if the gateway inclusion push-button needs an external pull-up resistor. I looked at the code (older code 1.3 something) and didn't see internal pull-ups enabled, yet in the instructions it does not mention to hook up an external pull-up resistor. Please advise...I have designed a gateway PCB with an external pull-up because I didn't see internal pull-ups enabled in the code.
