1.4 Beta

@John You can obtain the same result as the old waitForMessage by registering a callback. Have this callback set a flag and call process() in the loop, as hek suggests.
You could also turn things around and read and average your sensors from a (timer)interrupt handler.
But when you're not completely confident with using interrupts then its better to avoid them and just process everything from your loop(). Interrupts can introduce lots of nasty problems if you don't know exactly what you're doing!

You could also turn things around and read and average your sensors from a (timer)interrupt handler.

I will have to investigate if any of the components is using which timer and what will be influenced by it. I'm using an HD44780 alike as display so i'm not sure because never dived deep into the used library.

But when you're not completely confident

about 90%?

@hek
It would be nice if a waitForMessage like functionality would be included in 1.4.

RelayWithButtonActuator
incomingMessage should check if there is any payload or not. (could be bad package)
I use empty payload as a request for latest state (Yes I could do this some other way but I think it is logical..)

Because of the use of custom variables and the possibility of receiving and sending and of many sensor type possibilities is it possible to add a "sensor" type of S_OTHER (or alike)? I think this then would be in line of having var types V_VAR1, etc.. of which then would be something else then defined.

This will add the possibility to send other then sensor related data. This is of course possible but could semantic wise be more applicable.

@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?

@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.

@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?

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.

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 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?

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..

@hek
I'd like to ask for a small change to be made to the sleep function.

When we call gw.sleep(x) or gw.sleep(x,y,z) then the arduino disables the interrupt timer (to save power) that triggers the counter that drives millis(). So the value returned from millis() stalls when we sleep.

This is ok on our battery powered devices, since it's saving power, but makes it hard to determine how long it's been since we sent values to the gateway.

@hek
This is the first time I've ssh into vera, so I have no idea what I'm looking for.. I have 2 Everspring ST-814's that display correctly, and of course 2 MySensor sensor which did in 1.3, but not in 1.4b1.

The node will be transferring celsius data until it manage to receive settings from controller (this is done in the background) by setup().
Attach your failing sensor to the computer. Upload sketch with debug enabled. And look at the Serial monitor. Restart a sensor a few times .

To enable debugging: I Remove the "//" before the #define DEBUG ** in and ONLY in** the /libraries/MySensors/Config.h file ? Then upload the sketch again to the sensors? (I don't have to upload the gateway sketch also do I?)

I can only find MyConfig.h file, and DEBUG was already without the "//".

So I noticed something VERY strange. It seems when I have the sensors connected to the computer, they start reading in Fahrenheit, and once I pull the USB cable it reverts back to Celsius with-in 30-60 seconds..

Yep, I have no idea how to debug this. The debug window reads in Fahrenheit, (and in Vera), but 30-60 seconds after I disconnect the usb cable from my computer (at which point I can't use the serial com window) it reverts back to Celsius.

I've deleted one of the sensor nodes and child from Vera, cleared the eEPROM and re-install sketch and re-incuded back into Vera...

I just don't understand why it works while connected to my computer...

Do you think I can rule out my sensor hardware as it works with 1.3? Is there any way I can determine if it's being written to eEPROM while connected to the computer and then after it's disconnected (to see if it's getting overwritten)?