1.4 Beta
-
@hek Any tips on upgrading the June 1.4b1 to the August 1.4b1. I just attempted it with disastrous results. :)
I started off.
- Uploading the Vera files
- Re-compiled the new gateway (after changing the my IP Address and such)
- Re-complied the Repeaters
Just to get going. Both repeaters failed at startup with the standard FAIL in the debug logs. Wiping the Eeprom and trying again did not work. Dropping the repeaters for vera and re-including did not work? Finally went back to the June build and restored the vera from last night and then two other units failed to come back online. Had to replace the antennas on those two units to get them back on-line – BIZARRE.
- Do all the sensors have to be updated at once?
- Will existing sensors under the June 1.4b1 build co-exist with the August 1.4b1 Gateway build?
- Can we just recompile our existing June sketches under the new mySensors library as long as no compile errors show?
Thanks
Yes, you'll have to recompile/update them all as message format has changed. No need for wiping eeprom or re-include sensors. Also update Vera plugin.
Replacing antenna should not be necessary and I don't understand why that would change anything..
-
Yes, you'll have to recompile/update them all as message format has changed. No need for wiping eeprom or re-include sensors. Also update Vera plugin.
Replacing antenna should not be necessary and I don't understand why that would change anything..
@hek I had a look at the latest state of the 1.4 header format and saw the sender/last/destination have moved to the front position.
This means the protocol version is, once again, located at a different position w.r.t. 1.3 and earlier 1.4 version.
For software trying to interpret any MySensors message (e.g. my sniffer or a (future) MySensors version supporting different protocol versions) or software that checks the library version to match with its own version it becomes nearly impossible to detect which library version a message was sent with.
I propose to start any message, now and in the future, with a protocol version (use a full byte or use some remaining bits for protocol independent data) and stick to that. This makes life for sugested applications a lot easier.
Adding a version which has a different offset every time makes no sense...http://yveaux.blogspot.nl
-
@hek I had a look at the latest state of the 1.4 header format and saw the sender/last/destination have moved to the front position.
This means the protocol version is, once again, located at a different position w.r.t. 1.3 and earlier 1.4 version.
For software trying to interpret any MySensors message (e.g. my sniffer or a (future) MySensors version supporting different protocol versions) or software that checks the library version to match with its own version it becomes nearly impossible to detect which library version a message was sent with.
I propose to start any message, now and in the future, with a protocol version (use a full byte or use some remaining bits for protocol independent data) and stick to that. This makes life for sugested applications a lot easier.
Adding a version which has a different offset every time makes no sense...Sorry.. the sniffer slipped my mind. The purpose was to prepare for future encryption (keeping the changing "last"-field first) and potential split of the routing information and payload. Which would be necessary for supporting other transportation layers (like RadioHead). They might not be interested in any MySensors version-specifics first in the radio message.
Do you have any suggestion?
-
Sorry.. the sniffer slipped my mind. The purpose was to prepare for future encryption (keeping the changing "last"-field first) and potential split of the routing information and payload. Which would be necessary for supporting other transportation layers (like RadioHead). They might not be interested in any MySensors version-specifics first in the radio message.
Do you have any suggestion?
-
@hek I have another question: when sending from a sensor to a gateway the data can have all kinds of formats (text, byte, float etc) which comes out the gateway through the serial protocol. When sending the other way, I guess the serial data is always sent as text by the gateway to the sensor, right?
Too bad we can't also use different formats when sending through the serial api... Did you think about this? -
@Yveaux said:
It's in my post hek
Yes, you suggest to always have but that might not be possible if we choose some other transportation layer (which most probably will use the first bytes for it's own routing).
When sending the other way, I guess the serial data is always sent as text by the gateway to the sensor, right?
Too bad we can't also use different formats when sending through the serial api... Did you think about this?Yes, I've thought about it. We have a couple of options here. Start type:ing variables through the serial protocol (controller must send datatype) or have a hard coded variable->type map on arduino side. Both of these are valid options.
A binary serial protocol is also an option (could be an option when building gateway).. But that makes it harder to debug e.g. Arduino Serial Monitor. -
@Yveaux said:
It's in my post hek
Yes, you suggest to always have but that might not be possible if we choose some other transportation layer (which most probably will use the first bytes for it's own routing).
When sending the other way, I guess the serial data is always sent as text by the gateway to the sensor, right?
Too bad we can't also use different formats when sending through the serial api... Did you think about this?Yes, I've thought about it. We have a couple of options here. Start type:ing variables through the serial protocol (controller must send datatype) or have a hard coded variable->type map on arduino side. Both of these are valid options.
A binary serial protocol is also an option (could be an option when building gateway).. But that makes it harder to debug e.g. Arduino Serial Monitor.@hek said:
but that might not be possible if we choose some other transportation layer
Then the transportation layer data is not part of mysensors protocol. It's that simple!
IMHO This again boils down to nested protocol headers which we talked about before.
The routing info is part of transportation layer (it could even have its own version info) followed by the mysensors header ( starting with a version number) which tells us what's in the message. Then come the actual data, be it a value, presentation info or whatever. I can make a sketch of this structure if that helps in the discussion.http://yveaux.blogspot.nl
-
@hek said:
but that might not be possible if we choose some other transportation layer
Then the transportation layer data is not part of mysensors protocol. It's that simple!
IMHO This again boils down to nested protocol headers which we talked about before.
The routing info is part of transportation layer (it could even have its own version info) followed by the mysensors header ( starting with a version number) which tells us what's in the message. Then come the actual data, be it a value, presentation info or whatever. I can make a sketch of this structure if that helps in the discussion.I think we agree. Only problem is that I haven't split up the structure in mysensors-transportation/mysensors-header/mysensors-payload yet but if you look from the sniffer side this would not matter.
Please post you suggested structure (but in a new thread).
-
I think we agree. Only problem is that I haven't split up the structure in mysensors-transportation/mysensors-header/mysensors-payload yet but if you look from the sniffer side this would not matter.
Please post you suggested structure (but in a new thread).
I got this question from a friend and since I dont know the answer either;
I'm trying to figure out the sleep mode and if the radio module wakes up or not (via INT pin 2) .. but for me it does not seam to do this. Which sleep-modes does 1.4b have and how do I see if the message is for me, and if not continue sleep?
-
I got this question from a friend and since I dont know the answer either;
I'm trying to figure out the sleep mode and if the radio module wakes up or not (via INT pin 2) .. but for me it does not seam to do this. Which sleep-modes does 1.4b have and how do I see if the message is for me, and if not continue sleep?
The radio interrupts is not used at the moment.
It uses the following sleep modes
LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);or
LowPower.powerDown(SLEEP_XXXXS, ADC_OFF, BOD_OFF);Depending on if you want timer to wake up or not. Radio is always put to sleep.
For more details, check out MySensor.cpp. -
I'm trying to create my own controller in Node-Red.
My setup is as followed:
Motion Sensor arduino with standard example sketch <--> SerialGateway arduino with standard example sketch <--> USB <--> Node-Red (installed on Raspberry PI)My SerialGateway receives the request for a node ID (255;255;3;0;3;)
I then return a serial command: 255;255;3;0;4;1You can see my Node-Red output below:
For some reason my SerialGateway is not broadcasting my command. It's only repeating the above commands sevral times;
Am i using the correct protocol values or is there something else I should do?
-
I'm trying to create my own controller in Node-Red.
My setup is as followed:
Motion Sensor arduino with standard example sketch <--> SerialGateway arduino with standard example sketch <--> USB <--> Node-Red (installed on Raspberry PI)My SerialGateway receives the request for a node ID (255;255;3;0;3;)
I then return a serial command: 255;255;3;0;4;1You can see my Node-Red output below:
For some reason my SerialGateway is not broadcasting my command. It's only repeating the above commands sevral times;
Am i using the correct protocol values or is there something else I should do?
-
If it's working from your gateway Serial Monitor in IDE you must be doing something wrong in your program.
-
If it's working from your gateway Serial Monitor in IDE you must be doing something wrong in your program.
Got it working, but my solution is not very satisfying.
I swapt the sketches on my 2 arduino's.
Original arduino setup was:
SerialGatway - Arduino pro mini 3.3v (including Decoupling-Capacitor)
Motion Sensor - Arduino Uno (including Decoupling-Capacitor)Now the sketches are switched and it works.
Eventually I will be working with only Arduino pro mini's but still the original setup should have worked.
-
Got it working, but my solution is not very satisfying.
I swapt the sketches on my 2 arduino's.
Original arduino setup was:
SerialGatway - Arduino pro mini 3.3v (including Decoupling-Capacitor)
Motion Sensor - Arduino Uno (including Decoupling-Capacitor)Now the sketches are switched and it works.
Eventually I will be working with only Arduino pro mini's but still the original setup should have worked.
-
@warawara did you try clearing using clear eeprom? That helped me some times. Dont really know why some nodes just wont want to recieve packages..
-
Ok, So I took the plunge and upgraded to 1.4.b1, and everything went "OK" with one glaring exception...... All temperatures display in Celsius. No matter what I do, I can't seem to get it to display in Fahrenheit..
Any Idea's?
