1.4 Beta
-
Thanks, that worked. I thought I understood the message layout.. never seen that 0 before:)
-
@hek said:
It's a change in the serial protocol for 1.4.
Could you describe it better keeping in mind my problem with Relay? How the message should look like to turn on Relay? Previously message like this worked ok - 11;1;1;2;1.
-
-
-
I just tried to send myself a picture over the network. real ugly code but it worked.. thought if I put a small cam and someone rings on the doorbell or something.. :) (Right now I just read the data from SPI flash)
-
I've tried the lib for a while now and found the following:
Then using ack=1 the returned message is exacly the one I sent. No way of knowing if its a request or an ACK.
example:
Client sends
3;255;3;6;0 (Give me configuration 0 (btw, why not leave config as a byte 0-255 instead of hardcoing it? I could have plenty of uses for configuration-values.)
Gateway responds: 3;255;3;6;M and requests ack
client sends
3;255;3;6;M
my software tried to lookup config id 'M' (Not a big deal for letter, but what if its a number?)
maybe ACK should be some sort of incremental number in return in special message type. I dont really know what is best.
It would be great if GW resends the messsage automatically a couple of times (configurable) if ACK = 1.I've also noticed during DEBUG enabled that the message gets overwritten by old one, i.e.
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=11,pt=0,l=4,st=ok:test1 (18848a2)
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:2.0t1 (18848a2)
(message 2: test1, message 3: 2.0)Edit; One more thing
Do I really need one gw.process(); before each gw.send(..); in the loop? I seam to loose messages if I dont do like that.void loop()
{
delay(dht.getMinimumSamplingPeriod());gw.process();
float temperature = dht.getTemperature();
gw.send(msgTemp.set(temperature, 1));gw.process();
float humidity = dht.getHumidity();
gw.send(msgHum.set(humidity, 1));// gw.sleep(SLEEP_TIME); //Seems to break recieing message, loosing ~75%
}
-
I've tried the lib for a while now and found the following:
Then using ack=1 the returned message is exacly the one I sent. No way of knowing if its a request or an ACK.
example:
Client sends
3;255;3;6;0 (Give me configuration 0 (btw, why not leave config as a byte 0-255 instead of hardcoing it? I could have plenty of uses for configuration-values.)
Gateway responds: 3;255;3;6;M and requests ack
client sends
3;255;3;6;M
my software tried to lookup config id 'M' (Not a big deal for letter, but what if its a number?)
maybe ACK should be some sort of incremental number in return in special message type. I dont really know what is best.
It would be great if GW resends the messsage automatically a couple of times (configurable) if ACK = 1.I've also noticed during DEBUG enabled that the message gets overwritten by old one, i.e.
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=11,pt=0,l=4,st=ok:test1 (18848a2)
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:2.0t1 (18848a2)
(message 2: test1, message 3: 2.0)Edit; One more thing
Do I really need one gw.process(); before each gw.send(..); in the loop? I seam to loose messages if I dont do like that.void loop()
{
delay(dht.getMinimumSamplingPeriod());gw.process();
float temperature = dht.getTemperature();
gw.send(msgTemp.set(temperature, 1));gw.process();
float humidity = dht.getHumidity();
gw.send(msgHum.set(humidity, 1));// gw.sleep(SLEEP_TIME); //Seems to break recieing message, loosing ~75%
}
@Damme Other wireless protocols usually have a counter which is increased with each message. Returning the counter as an ack would be sufficient to correlate the ack and the original message.
Returning the whole message seems like overkill indeed...The send-methods could e.g. return the Id counter of the message sent, and an app waiting for an ack on that message should check for this value in any ack received (using some timeout)
-
Additional comment on config;
I think it should be request config, response config messages.I also think its a bit odd that the actuator reports as
gw.present(2, S_LIGHT);
but requests as
if (message.type==V_LIGHT) {V_LIGHT != S_LIGHT (2 vs 3)
I think the def should follow as much as possible.hope any of my thoughts are somewhat useful
-
Additional comment on config;
I think it should be request config, response config messages.I also think its a bit odd that the actuator reports as
gw.present(2, S_LIGHT);
but requests as
if (message.type==V_LIGHT) {V_LIGHT != S_LIGHT (2 vs 3)
I think the def should follow as much as possible.hope any of my thoughts are somewhat useful
-
I've tried the lib for a while now and found the following:
Then using ack=1 the returned message is exacly the one I sent. No way of knowing if its a request or an ACK.
example:
Client sends
3;255;3;6;0 (Give me configuration 0 (btw, why not leave config as a byte 0-255 instead of hardcoing it? I could have plenty of uses for configuration-values.)
Gateway responds: 3;255;3;6;M and requests ack
client sends
3;255;3;6;M
my software tried to lookup config id 'M' (Not a big deal for letter, but what if its a number?)
maybe ACK should be some sort of incremental number in return in special message type. I dont really know what is best.
It would be great if GW resends the messsage automatically a couple of times (configurable) if ACK = 1.I've also noticed during DEBUG enabled that the message gets overwritten by old one, i.e.
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=11,pt=0,l=4,st=ok:test1 (18848a2)
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:2.0t1 (18848a2)
(message 2: test1, message 3: 2.0)Edit; One more thing
Do I really need one gw.process(); before each gw.send(..); in the loop? I seam to loose messages if I dont do like that.void loop()
{
delay(dht.getMinimumSamplingPeriod());gw.process();
float temperature = dht.getTemperature();
gw.send(msgTemp.set(temperature, 1));gw.process();
float humidity = dht.getHumidity();
gw.send(msgHum.set(humidity, 1));// gw.sleep(SLEEP_TIME); //Seems to break recieing message, loosing ~75%
}
-
@Damme said:
// gw.sleep(SLEEP_TIME); //Seems to break recieing message, loosing ~75%
me just dumb here, delay(SLEEP_TIME); works. gw.sleep puts radio in sleep I guess.
-
@Damme Other wireless protocols usually have a counter which is increased with each message. Returning the counter as an ack would be sufficient to correlate the ack and the original message.
Returning the whole message seems like overkill indeed...The send-methods could e.g. return the Id counter of the message sent, and an app waiting for an ack on that message should check for this value in any ack received (using some timeout)
@Yveaux said:
The send-methods could e.g. return the Id counter of the message sent, and an app waiting for an ack on that message should check for this value in any ack received (using some timeout)
That mean you might have to rememeber the original message. The idea is to have all the information necessary in the callback.
In my example sketches (e.g. RelayActuator) the ack message actually changes the relay status when the ack comes back from gateway. If not full message came in you would have to keep buffers with sent messages and start matching counter-values. Much more complicated.But a message counter will probably be necessary if/when we start encrypting messages to prohibit replay attacks.
@Damme
I actually thought about having a bit in the message header which says if the message is an ack or not. With that implemented you would just call a msg.isAck() to determine if the incoming message is an ack message. Would that be ok?You shouldn't need to call gw.process() after each send. It is only necessary in the loop() section if you expect incoming messages or have enabled repeater mode.
I don't understand what you mean with messages getting overwritten with DEBUG enabled. Could you explain it a bit more (with an example?).
-
To pick up the discussions about existence or not of getTemp().
A better solution would probably be to create a MySensorsATMega328-subclass of the library which contains AtMega specific stuff such as sleep() and potentially getTemp().
This class should also implement the EEPROM specifics. -
@Yveaux said:
The send-methods could e.g. return the Id counter of the message sent, and an app waiting for an ack on that message should check for this value in any ack received (using some timeout)
That mean you might have to rememeber the original message. The idea is to have all the information necessary in the callback.
In my example sketches (e.g. RelayActuator) the ack message actually changes the relay status when the ack comes back from gateway. If not full message came in you would have to keep buffers with sent messages and start matching counter-values. Much more complicated.But a message counter will probably be necessary if/when we start encrypting messages to prohibit replay attacks.
@Damme
I actually thought about having a bit in the message header which says if the message is an ack or not. With that implemented you would just call a msg.isAck() to determine if the incoming message is an ack message. Would that be ok?You shouldn't need to call gw.process() after each send. It is only necessary in the loop() section if you expect incoming messages or have enabled repeater mode.
I don't understand what you mean with messages getting overwritten with DEBUG enabled. Could you explain it a bit more (with an example?).
@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. -
@Yveaux said:
The send-methods could e.g. return the Id counter of the message sent, and an app waiting for an ack on that message should check for this value in any ack received (using some timeout)
That mean you might have to rememeber the original message. The idea is to have all the information necessary in the callback.
In my example sketches (e.g. RelayActuator) the ack message actually changes the relay status when the ack comes back from gateway. If not full message came in you would have to keep buffers with sent messages and start matching counter-values. Much more complicated.But a message counter will probably be necessary if/when we start encrypting messages to prohibit replay attacks.
@Damme
I actually thought about having a bit in the message header which says if the message is an ack or not. With that implemented you would just call a msg.isAck() to determine if the incoming message is an ack message. Would that be ok?You shouldn't need to call gw.process() after each send. It is only necessary in the loop() section if you expect incoming messages or have enabled repeater mode.
I don't understand what you mean with messages getting overwritten with DEBUG enabled. Could you explain it a bit more (with an example?).
@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..)
