@InTranceWeTrust
There should be no need for anything in the controller. The gateway will reconstruct different messages from the blob and send them one by one to the controller (as if they were passed individually), assuming the registration is done as in the "no blob" case. But one should be careful about how many messages fit in one block, the MyBlob.set() will return false if the desired message will not fit in the available space and in this case one should do a send() and then construct a new block. Probably a "reset()" API should be added to MyBlob to ease re-using it instead of constructing a new one....

I have added a pull request for this (#1515).

Best Regards,
Constantin

Thank you @mfalkvidd !

The "smart sleep" feature seems indeed to do what I want. However, I see two issues for now (I am using Domoticz as Home Automation System):

1. In the controller description page you have mentioned, "Smart sleep feature" for Domoticz is "n", but I actually find in the Domoticz release history that it was actually implemented (since version 4.9700 - 2018?).
   "- Implemented: MySensors: support for SmartSleep option (gateway 2.x)". I also found some loose ends about this, and no convincing further information:
   https://www.domoticz.com/forum/viewtopic.php?t=13827
   https://github.com/domoticz/domoticz/issues/2394

2. if this is is implemented in the controller, it means it won't be very fast, especially because my gateway is in a remote location, connected through MQTT over VPN via 3G (unless I create a separate Domoticz instance at the remote location itself).

Any new thoughts on this?

Best Regards,
Costa

I have decided to implement this myself.
https://github.com/cpetra/MySensors
The code seems to work. I have added a new "MyBlob" object that can handle multiple sensor data in one message, as I wanted to keep the MyMessage.h header clean. I will probably add a pull request when I get the time to document it.
The usage is quite simpe:

#ifdef USE_BLOB 
MyMessage msgBlob(0, V_BLOB); 
#else 
MyMessage msgTEMPERATURE(CHILD_ID_TEMPERATURE, V_TEMP); 
MyMessage msgHUMIDITY(CHILD_ID_HUMIDITY, V_HUM); 
#endif 

and then:

  #ifdef USE_BLOB 
  MyBlob blob(&msgBlob); 
  blob.set(V_TEMP, CHILD_ID_TEMPERATURE , temperature, 1); 
  blob.set(V_HUM, CHILD_ID_HUMIDITY, humidity, 1); 
  blob.setBattery(batt_level); 
  send(msgBlob); 
  #else 
  send(msgTEMPERATURE.set(temperature, 1)); 
  wait(10); 
  send(msgHUMIDITY.set(humidity, 1)); 
  wait(10); 
  sendBatteryLevel(batt_level); 
  #endif 

The sketch I have added uses Adafruit_HTU21DF.h, where I have also changed the delay() to sleep(),
I have the following results when reading and sending the data. The times I have are now:

T on: 23 avg: 31 min: 19 max: 443
T on: 95 avg: 108 min: 72 max: 510

On average, 31 ms vs 108 when sending temperature/humidity/battery ( I realize the battery level doesn't need to be sent too often, but still...)
Considering a 300mA CR2032 battery with a 5 minute update time, it can last a whole year.
There are probably other ways of packing up more data (e.g. one doesn't really need 5 bytes to send temperature information with one decimal precision, 3 bytes should be enough for environmental measurement) but that's another story.
.Some logs from the gateway in the generic case:

Feb 03 07:19:59 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-99
Feb 03 07:19:59 DEBUG RFM69:CSMA:RSSI=-102
Feb 03 07:19:59 DEBUG TSF:MSG:READ,1-1-0,s=0,c=1,t=0,pt=7,l=5,sg=0:17.2
Feb 03 07:19:59 DEBUG GWT:TPS:TOPIC=mysensors-out/1/0/1/0/0,MSG SENT
Feb 03 07:19:59 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-91
Feb 03 07:19:59 DEBUG RFM69:CSMA:RSSI=-100
Feb 03 07:19:59 DEBUG TSF:MSG:READ,1-1-0,s=1,c=1,t=1,pt=7,l=5,sg=0:49.6
Feb 03 07:19:59 DEBUG GWT:TPS:TOPIC=mysensors-out/1/1/1/0/1,MSG SENT
Feb 03 07:19:59 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-74
Feb 03 07:19:59 DEBUG RFM69:CSMA:RSSI=-97
Feb 03 07:19:59 DEBUG TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:0
Feb 03 07:19:59 DEBUG GWT:TPS:TOPIC=mysensors-out/1/255/3/0/0,MSG SENT

And in the "blob" case:

Feb 03 07:22:02 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-99
Feb 03 07:22:02 DEBUG RFM69:CSMA:RSSI=-99
Feb 03 07:22:02 DEBUG TSF:MSG:READ,1-1-0,s=0,c=1,t=57,pt=6,l=20,sg=0:E10000D4758A4101E1010140204D42012300FF00
Feb 03 07:22:02 DEBUG GWT:TPS:TOPIC=mysensors-out/1/0/1/0/0,MSG SENT
Feb 03 07:22:02 DEBUG GWT:TPS:TOPIC=mysensors-out/1/1/1/0/1,MSG SENT
Feb 03 07:22:02 DEBUG GWT:TPS:TOPIC=mysensors-out/1/255/3/0/0,MSG SENT

Let me know what you think. Eventually let me know what other parts I should touch, as I'm not that familiar with the whole code...

Best Regards,
Constantin

Hi,

I've been playing with mysensors for some days now and I can say that, for now, it is very well suited for my needs.
There are some parts that I had some trouble with though, and I would like to bring this up.
For now, I have used rfm69CW/HCW and some BMP280 sensors, but I plan to switch to HTU21d because I only need temperature/humidity for most of my room monitoring devices (haven't yet gotten the time to create a power profile for those yet, though).
For BMP280 (it was supposed to be a BME280 but it seems I got scammed again on Aliexpress) I have a good understanding of its power profile.
When sending humidity/baro/temperature/battery, I need to add a sleep(5-10) between sends otherwise it takes between 300ms-1000ms to send everything - I assume is some sort of collision (I've seen some discussions around this subject). If the sleeps are added, I get around 100ms for the RF activity. If sending a single data type, I get lower than 20ms for one send.
As the 100ms effectively doubles the time spent in the whole iteration comparing to a single message, I was wondering if there is any possibility to combine multiple sensor data in one message. 24 bytes seem more than enough for what I need. I have also looked through the code but it seems to me that messages can have only one sensor data. I am thinking that maybe a special new type could be used that causes the gateway to reconstruct multiple messages from that one if a certain structure is used. But I don't want to get too much into it without asking around if there is any plan for that (or maybe there's already something not obvious to me).
If there isn't and there's no plan for it, I would like to look into it when I get some time.

Thanks,
Constantin

I have added a pull request for this (#1515).

Best Regards,
Constantin

@InTranceWeTrust
There should be no need for anything in the controller. The gateway will reconstruct different messages from the blob and send them one by one to the controller (as if they were passed individually), assuming the registration is done as in the "no blob" case. But one should be careful about how many messages fit in one block, the MyBlob.set() will return false if the desired message will not fit in the available space and in this case one should do a send() and then construct a new block. Probably a "reset()" API should be added to MyBlob to ease re-using it instead of constructing a new one....

I have decided to implement this myself.
https://github.com/cpetra/MySensors
The code seems to work. I have added a new "MyBlob" object that can handle multiple sensor data in one message, as I wanted to keep the MyMessage.h header clean. I will probably add a pull request when I get the time to document it.
The usage is quite simpe:

#ifdef USE_BLOB 
MyMessage msgBlob(0, V_BLOB); 
#else 
MyMessage msgTEMPERATURE(CHILD_ID_TEMPERATURE, V_TEMP); 
MyMessage msgHUMIDITY(CHILD_ID_HUMIDITY, V_HUM); 
#endif 

and then:

  #ifdef USE_BLOB 
  MyBlob blob(&msgBlob); 
  blob.set(V_TEMP, CHILD_ID_TEMPERATURE , temperature, 1); 
  blob.set(V_HUM, CHILD_ID_HUMIDITY, humidity, 1); 
  blob.setBattery(batt_level); 
  send(msgBlob); 
  #else 
  send(msgTEMPERATURE.set(temperature, 1)); 
  wait(10); 
  send(msgHUMIDITY.set(humidity, 1)); 
  wait(10); 
  sendBatteryLevel(batt_level); 
  #endif 

The sketch I have added uses Adafruit_HTU21DF.h, where I have also changed the delay() to sleep(),
I have the following results when reading and sending the data. The times I have are now:

T on: 23 avg: 31 min: 19 max: 443
T on: 95 avg: 108 min: 72 max: 510

On average, 31 ms vs 108 when sending temperature/humidity/battery ( I realize the battery level doesn't need to be sent too often, but still...)
Considering a 300mA CR2032 battery with a 5 minute update time, it can last a whole year.
There are probably other ways of packing up more data (e.g. one doesn't really need 5 bytes to send temperature information with one decimal precision, 3 bytes should be enough for environmental measurement) but that's another story.
.Some logs from the gateway in the generic case:

Feb 03 07:19:59 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-99
Feb 03 07:19:59 DEBUG RFM69:CSMA:RSSI=-102
Feb 03 07:19:59 DEBUG TSF:MSG:READ,1-1-0,s=0,c=1,t=0,pt=7,l=5,sg=0:17.2
Feb 03 07:19:59 DEBUG GWT:TPS:TOPIC=mysensors-out/1/0/1/0/0,MSG SENT
Feb 03 07:19:59 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-91
Feb 03 07:19:59 DEBUG RFM69:CSMA:RSSI=-100
Feb 03 07:19:59 DEBUG TSF:MSG:READ,1-1-0,s=1,c=1,t=1,pt=7,l=5,sg=0:49.6
Feb 03 07:19:59 DEBUG GWT:TPS:TOPIC=mysensors-out/1/1/1/0/1,MSG SENT
Feb 03 07:19:59 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-74
Feb 03 07:19:59 DEBUG RFM69:CSMA:RSSI=-97
Feb 03 07:19:59 DEBUG TSF:MSG:READ,1-1-0,s=255,c=3,t=0,pt=1,l=1,sg=0:0
Feb 03 07:19:59 DEBUG GWT:TPS:TOPIC=mysensors-out/1/255/3/0/0,MSG SENT

And in the "blob" case:

Feb 03 07:22:02 DEBUG RFM69:SAC:SEND ACK,TO=1,RSSI=-99
Feb 03 07:22:02 DEBUG RFM69:CSMA:RSSI=-99
Feb 03 07:22:02 DEBUG TSF:MSG:READ,1-1-0,s=0,c=1,t=57,pt=6,l=20,sg=0:E10000D4758A4101E1010140204D42012300FF00
Feb 03 07:22:02 DEBUG GWT:TPS:TOPIC=mysensors-out/1/0/1/0/0,MSG SENT
Feb 03 07:22:02 DEBUG GWT:TPS:TOPIC=mysensors-out/1/1/1/0/1,MSG SENT
Feb 03 07:22:02 DEBUG GWT:TPS:TOPIC=mysensors-out/1/255/3/0/0,MSG SENT

Let me know what you think. Eventually let me know what other parts I should touch, as I'm not that familiar with the whole code...

Best Regards,
Constantin

Hi,

I've been playing with mysensors for some days now and I can say that, for now, it is very well suited for my needs.
There are some parts that I had some trouble with though, and I would like to bring this up.
For now, I have used rfm69CW/HCW and some BMP280 sensors, but I plan to switch to HTU21d because I only need temperature/humidity for most of my room monitoring devices (haven't yet gotten the time to create a power profile for those yet, though).
For BMP280 (it was supposed to be a BME280 but it seems I got scammed again on Aliexpress) I have a good understanding of its power profile.
When sending humidity/baro/temperature/battery, I need to add a sleep(5-10) between sends otherwise it takes between 300ms-1000ms to send everything - I assume is some sort of collision (I've seen some discussions around this subject). If the sleeps are added, I get around 100ms for the RF activity. If sending a single data type, I get lower than 20ms for one send.
As the 100ms effectively doubles the time spent in the whole iteration comparing to a single message, I was wondering if there is any possibility to combine multiple sensor data in one message. 24 bytes seem more than enough for what I need. I have also looked through the code but it seems to me that messages can have only one sensor data. I am thinking that maybe a special new type could be used that causes the gateway to reconstruct multiple messages from that one if a certain structure is used. But I don't want to get too much into it without asking around if there is any plan for that (or maybe there's already something not obvious to me).
If there isn't and there's no plan for it, I would like to look into it when I get some time.

Thanks,
Constantin

@frapell
I am having the same issue with Raspberry PI zero W, I get an awful range (less than 2 meters) with the default build values. It seems the default power setting for RFM69HCW are 5dB. Also, for RPI Zero W it seems the 3.3V pin supplies only 50mA and I have also added an extra 3.3V regulator (should not be the case for RPI3+).
I have now compiled the gateway using the following and got a better range indoors:

./configure --my-transport=rfm69 --my-rfm69-frequency=915 --my-is-rfm69hcw --my-gateway=mqtt --my-controller-ip-address=192.168.1.41 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --extra-cxxflags="-DMY_RFM69_MAX_POWER_LEVEL_DBM=20 -DMY_RFM69_TX_POWER_DBM=20 -DMY_DEBUG_VERBOSE_RFM69"

Look for "LEVEL" in the logs to check that the power level is the correct one. I don't know how mysensors handles the power range (expected to see it increasing it by itself no answers, but I could not get it working otherwise).

Maybe it helps.

Best Regards,
Costa

Hi,

Increasing the MY_SMART_SLEEP_WAIT_DURATION_MS would probably work, but I assume this waiting happens while the sensor sketch is running (at least the RF needs to be powered on), thus decreasing battery life.
But I think I will give it a try soon and see what happens.
Thanks for the precious info!

BR,
Costa

Thank you @mfalkvidd !

The "smart sleep" feature seems indeed to do what I want. However, I see two issues for now (I am using Domoticz as Home Automation System):

1. In the controller description page you have mentioned, "Smart sleep feature" for Domoticz is "n", but I actually find in the Domoticz release history that it was actually implemented (since version 4.9700 - 2018?).
   "- Implemented: MySensors: support for SmartSleep option (gateway 2.x)". I also found some loose ends about this, and no convincing further information:
   https://www.domoticz.com/forum/viewtopic.php?t=13827
   https://github.com/domoticz/domoticz/issues/2394

2. if this is is implemented in the controller, it means it won't be very fast, especially because my gateway is in a remote location, connected through MQTT over VPN via 3G (unless I create a separate Domoticz instance at the remote location itself).

Any new thoughts on this?

Best Regards,
Costa

Hi,

Glad to meet you all
I am not (yet) a user of MySensors, but I am actually looking for a software alternative to a custom setup which implies battery sensors and actuators.

Maybe this feature already exists (and possibly it is also trivial), but unfortunately I'm unable to find a description.

I have built and programmed my own gateway and devices using NRF24l01+ some years ago. I have a special battery powered switch which actually sends some information and then waits a few milliseconds for a command that should come from the gateway and then goes back to sleep for a couple of minutes (I am using Ack payloads with separate channel for this device). However, every two to four weeks, it stops receving the data and unless I power cycle the gateway altogether it does not handle ACKs again. I won't get into more details as I have also other reasons to replace my setup (and I am almost sure this is a hardware issue as I have tried to debug this quite extensively with no positive result).

So, my question is this: Is MySensors (NRF24L01 gateway) able to store a command directed to a dormant device and, when that device wakes up and sends a status message, to receive that as quick as possible?
Or... how can this be done using the available setup and how quick it can be? (for example, in my setup, the gateway acts as MQTT subscriber for the device and prepares the command for when the devices wakes up thus skipping the overhead of MQTT connection/setup/etc).

Thanks,
Costa