MySensors 1.4 Released
-
@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).
-
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 -
@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 -
@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 -
@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 -
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 -
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.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.
@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.
RJ_Make
