MySensors 1.4 Released
-
CONGRATULATIONS Henrik and all those that made this release happen. It is a wealthy step up from 1.3...
@marceltrapman said:
CONGRATULATIONS Henrik and all those that made this release happen. It is a wealthy step up from 1.3...
And the future looks even brighter with :
- Multi radio support
- Understandable split between devices vs variables.
- OTA improvements
- MySensors hardware!!
- ...and hopefully some kind of cloud enabled node-controller. Yeah .. I know it takes an awful lot of time to get that up and running.
- Runner ups: Encryption, Time awareness and scheduling
Hope to see more controller plugins and fun projects from the community.
Thanks to all donors and code contributors! Really! :heart: You make the project progress!
-
Great work, Henrik!
And good work on fostering a community of cats as well!
Donation made in honor of the release.
-
Happy to say that we're now live with 1.4!
Visit http://www.mysensors.org for loads of new content .
-
Congratulations!!
-
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. :clap: :clap: :clap: :clap: :clap: :clap: :clap:
@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. :clap: :clap: :clap: :clap: :clap: :clap: :clap:
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!!!!
-
Happy to say that we're now live with 1.4!
Visit http://www.mysensors.org for loads of new content .
@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?
-
@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?
@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 !
z-wave - Vera -> Domoticz
rfx - Domoticz <- MyDomoAtHome <- Imperihome
mysensors -> mysensors-gw -> Domoticz -
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:
-
@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 ?
-
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.
-
@epierre said:
except for INTERNAL as it seems.
Yes, true.
In the LA I only see time as new, right ?
:question:
could the sensor soop on startup to get the data, but anyway manage reading the status of the sensor ?
:question:
-
@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.
-
@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:
-
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).
