1.4 Beta

[Yveaux]

@hek said:

That mean you might have to rememeber the original message.

You have to remember it anyway when you regard the message as lost after some time without an ack and you decide to send the message again. Only for a simple sensor node which sends a sensor value with ack, waits for an ack reply and then continues with the next sensor value this wouldn't be necessary. When a single node has multiple messages with ack 'in flight', you definately need message buffering.
This is independent from the ack message format IMHO.

I also think message buffering and retrying, when implemented, should be part of the MySensors library.
This improves realiability even more than with the NRF24 ack's enabled and avoids putting the retry-burden on the clients of the library.

[Damme]

@hek said:

I don't understand what you mean with messages getting overwritten with DEBUG enabled. Could you explain it a bit more (with an example?).

here is a serial output from one of my nodes
repeater started, id 3
send: 3-3-0-0 s=255,c=0,t=18,pt=0,l=15,st=fail:1.4b1 (18848a2)
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=4,st=fail:test1 (18848a2)
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=fail:2.0t1 (18848a2)
send: 3-3-0-0 s=0,c=0,t=7,pt=0,l=15,st=fail:1.4b1 (18848a2)
send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=15,st=fail:1.4b1 (18848a2)
send: 3-3-0-0 s=2,c=0,t=3,pt=0,l=15,st=fail:1.4b1 (18848a2)
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,st=fail:1.4b1 (18848a2)

and the sketch has: gw.sendSketchInfo("test", "2.0");

yes, I know they all failed, I'm using the microwave oven atm, it kills the channel 76 (usually uses 21 but forgot to change last time, works better for me here..)

[hek]

@Damme said:

send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=fail:2.0t1 (18848a2)

Ahh.. The strings-payloads don't seem to be terminated correctly.

[Yveaux]

@hek said:

A better solution would probably be to create a MySensorsATMega328-subclass of the library

I wouldn't restrict to the Atmega328. Quite some AVR's have this or simular behaviour and it would be nice to have a single library usable for all (e.g. using #ifdef's if absolutely necessary).
Seems like you're trying to move towards board- and cpu-support packages, like Linux does...

Another way to tackle it is to create a separate library to read the AVR's internal 'sensors' like the temperature sensor and e.g. the VCC voltage (as I did in https://github.com/Yveaux/arduino_vcc) and another one for persistent storage (EEPROM), and one for power management (sleep). This approach seems to follow the Arduino-way of creating a library for every 'function'.

It all depends on whether you think big and target different hardware (MPU) platforms or if you want to stick with the Arduino (or even only the ATmega328). When porting MySensors to the RPi it would be very nice if the MySensors library and examples would directly compile on both platforms.
This requires libraries to have a clear interface which doesn't limit portability to one platform or architecture.

[Damme]

Hello

I was looking in the nrf24l01 datasheet and found "Setup of Automatic Retransmission"
Is this something that mysensors use?

[Yveaux]

@Damme at least in the 1.4beta release. I think it's disabled in 1.3

[hek]

Yep, as @Yveaux says we use it it 1.4.

[lodewyk]

Hi guys,

I just got relays working with but struggling requesting a variable value on Beta 1.4.

My set variable commands looks as follow.

Switching On - > 1;1;1;0;2;1 (work as expected)
Off -> 1;1;1;0;2;0 (work as expected)

Request variable for the same relay -> 1;1;2;0;2; (sets the relay to 0 ???)

Can someone confirm if my request variable command is correct and if not what should it be?

Thanks

[Damme]

@lodewyk I use this:
void incomingMessage(const MyMessage &msg) {
// We only expect one type of message from controller. But we better check anyway.
if (msg.type==V_LIGHT) {
if (strlen(msg.getString())==0) {
gw.send(message.setSensor(msg.sensor).setType(V_LIGHT).set(digitalRead(msg.sensor-1+RELAY_1)?RELAY_ON:RELAY_OFF));
} else {
digitalWrite(msg.sensor-1+RELAY_1, msg.getBool()?RELAY_ON:RELAY_OFF);
gw.saveState(msg.sensor, msg.getBool());
}
}
}

(How do i use [code] ?? I start to hate this forum :P)

[hek]

@lodewyk

The relay example does not support requesting state. You must add some code in incomingMessage() to handle incoming request-messages (and reply to them).

To reply incoming request-command in incomingMessage for the RelayActuator-example do something like this (note I have not compiled/tested this)

if (mGetCommand(msg) == C_REQ) {
     mSetCommand(msg, C_SET);
     msg.setDestination(msg.getSender());
     msg.set(gw.loadState(msg.getSensor());
     gw.send(msg); 
} else (
    // Do the normal stuff here
}

[lodewyk]

@DAMME and @HEK

Thanks , very helpful.

I got so occupied with the commands and never thought about the sensor code.

Thanks

[lodewyk]

This post is deleted!

[lodewyk]

This post is deleted!

[hek]

@Damme said:

(How do i use [code] ?? I start to hate this forum :P)

This forum uses markdown. If you need help, press the little questionmark-icon in the compose window. http://daringfireball.net/projects/markdown/syntax

To decorate your codeblock use 4 spaces or one tab character first on each line.

[Yveaux]

@lodewyk hey man, you've got -2 posts.... How's that possible?

[hek]

Pushed a few new changes/bugfixes. Sorry for the slow progress. Had to wait until we got home and had the chance to do some verification.

• Ack bit in header indicating if message is an ack (see RelayWithButton for an example how to read it out).
• Sleep functions now takes unsigned long. This allows sensor to sleep for than 30 sec ;)
• Corrected string termination

https://github.com/mysensors/Arduino/commits/development

[hek]

A major code drop coming from @ToSa has now been merged into 1.4. It contains:

• The new MySensors Bootloader supporting Over-the-air sketch updates ("client"-side).
• A simple NodeJs Controller to test the OTA stuff ("server"-side).
• Changes to cope with new sketch meta data stored in EEPROM and conversion between serial protocol/binary data and some new STREAM command types added.
• A new internal command has also been added to allow resetting a node remotely.

A more detailed change log can be found here:
https://github.com/ToSa27/Arduino/commits/development

I haven't had time to test myself yet but everything has been verified by @ToSa and is reported working. He is on a business trip right now so advanced bootloader questions have to wait until he's back.

[marceltrapman]

@hek Sounds like a good step forward!
Only one boot loader question: does this mean we can use an external boot loader or do we have to use an external boot loader now?

[hek]

@marceltrapman

The OTA stuff is optional. But if you want to be able to hot deploy sketches over the air, you have to install the MySensors bootloader.

[Damme]

@hek There are still some problem with string termination,

repeater started, id 3
send: 3-3-0-0 s=255,c=0,t=18,pt=0,l=15,st=fail:1.4b1 (18848a2)
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=9,st=fail:Relaytest848a2)
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=fail:1.0aytest848a2)
read: 5-5-0 s=11,c=1,t=1,pt=0,l=4:58.4
send: 5-3-0-0 s=11,c=1,t=1,pt=0,l=4,st=fail:58.4
send: 3-3-0-0 s=10,c=1,t=0,pt=0,l=5,st=fail:26.20