Posts made by bilbolodz

First batch of devices arrived. Looks fine. I hope I will manage to install it in garden to the end of the week.

"Your code your rules" but I'm little surprised with your standpoint.

@anticimex OK maybe I will try but I think it could be a good idea to extend you "migration guide".

OK I will try it today. Yesterday I've done such procedure (without success) but now I've realised that I've used OLD (2.1) personalisation script (saved on disk) but loaded GW code compiled with 2.2 library. Probably that's an issue.

So I should first "personalise" ESP8266 device with "standard personalising sketch" and than upload my GW code with #define MY_SIGNING_SOFT. Right?

So it means that (If I want use signing) I'm stuck with mysensors version 2.1?
I'm not able compile new code (using 2.2) and upload it over OTA because I will loose signing right (without changeing EEPROM content)?
I think there should be a way to migrate sketch (which is using soft signing) from 2.1 to 2.2 with OTA. Secure sending of keys actually is NOT a problem because (as I understood) new in 2.2 is "only checksum" of EEPROM.
So if I have "2.1 mysensors library" personalized devices, it's possible to write a program which gets existing data from EEPROM calculate checksum and write it to EEPROM (maybe also migrating other structures if there were other changes). Such sketch can be in safe way transferred via OTA because it doesn't contain any secret information. Then I can upload new (using 2.2 library) version of my sketch and I will have working "2.2" devices without touching it (only OTA). What do you think about it?

Actually now I've realised (luckily) that in these "hard to get devices" I'm using hardware signing so it should be not a problem (?)

Is signing for ESP8266 gateway supported? I know that hardware signing is NOT supported but how about software? If so should be personalization in usual way (using sketch from examples) like "arduino nano" nodes?

I've a lot devices with very hard physical access to them. I'm using OTA to change firmware so please describe how to implement "new 2.2 checksum feature" into existing sketch using OTA.

@mfalkvidd said in Return value of bool send(MyMessage &msg, const bool ack = false);:

@bilbolodz just to check: are you sure there are no repeaters or other gateways within range?

I've to check more thoroughly but rather not.

@pjr Thank you. I'm already using software ack (and message resending after timeout) for get reliable radio transport. According hardware ack:

Hardware ack is what I get when using send(msg, true) and some other functions like present, sendSketchInfo and sendBatteryLevel

    Hardware ack is hop-to-hop acknowledgment
    Sending is a blocking function which returns true if an ack was received and false if ~70ms passed without receiving an hardware ack.
    Sending ack is handled automatically by the library(/radio)
    Receiving an ack is handled automatically by the library
    Re-send needs to be handled manually in each sketch (a while-loop with a counter counting up to maxRetries and using wait() between each resend seems to be the most common solution)

sounds nice but above statement seems to be not true in my case: after complete node registration in GW send function returns always true even GW is powered off.... I've studied source and looks that "in the lowest level of code" send function outcome comes from: drivers/RF24/RF24.cpp function:

LOCAL bool RF24_sendMessage(const uint8_t recipient, const void* buf, const uint8_t len)
{
	uint8_t RF24_status;
	RF24_stopListening();
	RF24_openWritingPipe( recipient );
	RF24_DEBUG(PSTR("RF24:SND:TO=%d,LEN=%d\n"),recipient,len); // send message
	// flush TX FIFO
	RF24_flushTX();
	// this command is affected in clones (e.g. Si24R1):  flipped NoACK bit when using W_TX_PAYLOAD_NO_ACK / W_TX_PAYLOAD
	// AutoACK is disabled on the broadcasting pipe - NO_ACK prevents resending
	RF24_spiMultiByteTransfer(recipient == BROADCAST_ADDRESS ? RF24_WRITE_TX_PAYLOAD_NO_ACK :
	                          RF24_WRITE_TX_PAYLOAD, (uint8_t*)buf, len, false );
	// go, TX starts after ~10us
	RF24_ce(HIGH);
	// timeout counter to detect HW issues
	uint16_t timeout = 0xFFFF;
	do {
		RF24_status = RF24_getStatus();
	} while  (!(RF24_status & ( _BV(RF24_MAX_RT) | _BV(RF24_TX_DS) )) && timeout--);
	// timeout value after successful TX on 16Mhz AVR ~ 65500, i.e. msg is transmitted after ~36 loop cycles
	RF24_ce(LOW);
	// reset interrupts
	RF24_setStatus(_BV(RF24_TX_DS) | _BV(RF24_MAX_RT) );
	// Max retries exceeded
	if(RF24_status & _BV(RF24_MAX_RT)) {
		// flush packet
		RF24_DEBUG(PSTR("!RF24:SND:MAX_RT\n"));	// max retries, no ACK
		RF24_flushTX();
	}
	RF24_startListening();
	// true if message sent
	return (RF24_status & _BV(RF24_TX_DS));
}

so it's from RF24 status register. I've to check how it's working on other RF24 modules. I've read that there are some comparability problems with non original Chinese clones of NRF24L01 chipset.

According MySensorsCore.h function bool send(MyMessage &msg, const bool ack = false) should return " true if message reached the first stop on its way to destination"

/**
* Sends a message to gateway or one of the other nodes in the radio network
*
* @param msg Message to send
* @param ack Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.
* @return true Returns true if message reached the first stop on its way to destination.
*/
bool send(MyMessage &msg, const bool ack = false);

In my case (using ACK options) it always return true regardless state of gateway (I've physically disconnected GW from USB after sensor startup/registration phase..... I'm using 2.1.1 version and RF24 transport What could be wrong?

I know it's very good rule.

OK I will probably fix my parents.

@gohan Static parent id would solve my problem BUT what if one repeaters (Murphy's law: most important) fail? 1/3 of my node network gone..... If I can blacklist some nodes (very distant from sensor) I can enable repeater feature on more nodes and have more redundant network. Similar with "static with backup": I can put more repeaters talking with more PA power and be 100% sure that node will talk to controller via one of "preferred parent".
Of course it's just my idea but maybe it's worth to think about it?

Now I've limited number of repeaters (4 in each corner of the house) and my problems with connectivity are less frequent but yes: from time to time my nodes are jumping to other repeater and in some cases there is a problem with RF link.

@gohan said in Semi static parent modification:

Did you have issues with repeaters since you are asking how to increase reliability?

Sorry but I don't quite understand you.....

It WAS tested but "in the middle of night" I've chosen WRONG firmware.....

I think it's a good idea to implement OTA "pre flash" validation. There should a possibility to define some HARDWARE_ID into sketch, modify OTA message to tell node "these new sketch is for XYZ HARDWARE_ID" and add some predefined function (as validate_OTA()) to block flashing if code is NOT for these hardware.
Accidentally I've flashed node mounted in a field and very well water protected with a wrong HEX. Dissembling module in "the middle of field", cleaning contacts from protecting grease, flashing it and protecting again was VERY painful......

Some background information:

I've bunch (over 30) nodes (NRF24) in my garden, there are working as lamp switches. I'm also using message signing. Because of RF range and required good signal quality (signing demands real stable RF network) I'm using repeaters.
In my code I'm using:

int8_t myParrentNodeId;
int8_t myRF24PALelel;

#define MY_PARENT_NODE_ID myParrentNodeId
#define MY_RF24_PA_LEVEL myRF24PALelel

trick to change preferred parent for nodes without needs of having different sketch image for each node and reflashing.

Unfortunately sometimes (because of unknown reason) node changes parent node to some distant repeater node and communication with these node (over "new parent") is very poor. It's also very hard to recover node from such state (reboot command needs signing, signing needs good radio connection, radio link is poor because node is using very distant repeater).

I've some ideas which could be implemented to remedy such situations:

1. Possibility to BLACKLIST some repeaters - it should be a array(?) in RAM/EEPROM which contain IDs of forbidden parents

2. Possibility to declare " MY_PARENT_NODE_IS_STATIC" but with fixed (in RAM or EEPROM) backup parrent ID. It will allow to limit possible parent to two good (in range) nodes but not break connectivity in case of primary parent failure

3. Better RF link quality verification to be 100% sure that whole path to controller is performing well.

4. It could be also a good idea to make possible enable/disable working node "as parent" without recompilation (easier tunning of large Mysensors network).

Sorry you are right. If you need to check "complete path" fetching time from controller is probably good way to do it.

@hyla You can use function: isTransportReady(). Confirmed working.

I mean: what is the size of @kalina designed PCB.

What's the size of these PCB?

@kalina said in NRF24L01 SMD to DIP converter:

For example, 20 pcs with delivery (to Poland) cost 11$ on PCBWay.

I've never used PCBWay but I will add it to "my list".

@kalina Thanks.

At the begging quick question: are you sure that all is fine with drills? Some gerber renders in PCB factories show strange results (pcbs.io and oshpark.com).

I've maid a quick research with comparison of cost (I've always took "the cheapest product and shipment option):

• www.seeedstudio.com 10 pcs 4.90 USD + shipment 11.30 USD - (PCB max size 100 mm x 100m)
• pcbs.io 4 pcs 1.50 USD + shipment free (probably problems with drills need to be checked more throughly)
• oshpark.com 3 pcs 1.85USD + shipment free (probably problems with drills need to be checked more throughly)
• dirtypcbs.com "protopack" (at least 10 pcs maybe more) 11.95 USD + 2 USD shipment (PCB max size 50mm x 50m, factory complaining after ZIP upload: "No board outline (.GML/.GKO/.GBR) file found")

Of course it depends of "someone needs" but I think it could be a good idea to prepare "panelized version" with a few pcs of PCB which fits into PCB factory needs (dirtypcbs.com: 5cmx5cm, www.seeedstudio.com 10cmx10cm) for a "batch order" it should be more costs efficient.

@kalina Now "for real": I will be more than happy if you provide gerber files for PCB factory and thank you very much for you work.

@kalina YEP

@kalina Cheater

@mfalkvidd Yes but it's ONLY for "normal version of SMD". Versions with PA have a little different pinout.

I'm looking for PCB which allow mount NRF24K01 SMD modules (version with PA and without) into existing Mysensors device prepered for DIP version of NRF. Any ideas?

@mfalkvidd said in Repeatrer level limit (NRF24L01 transport):

Everything in MySensors started off in the development branch

If you are using dev branch please test my sketch and check changing power mode with I_SIGNAL_REPORT_REQUEST message or transportGetSignalReport(const signalReport_t signalReport) function.

It looks that I've achieved my goal. I'm able dynamically change parent id node (proved in lab) and power level (don't have idea how to check it). You can send V_VAR1 message with number of preferred parent or V_VAR2 with requested power (values: 0 - RF24_PA_MIN, 1 - RF24_PA_LOW, 2 - RF24_PA_HIGH, RF24_PA_MAX) and then REBOOT node (required to changes take effect). Version of sketch reported to controller is changed dynamically depends of set power level.

My "repeater: code bellow:

#define SKETCH_NAME "Repeater Node L1"
#define SV "1.0.1" 
#define MY_RADIO_NRF24
#define MY_REPEATER_FEATURE

int8_t myParrentNodeId;
int8_t myRF24PALevel;

#define MY_PARENT_NODE_ID myParrentNodeId
#define MY_RF24_PA_LEVEL myRF24PALevel

#include <MySensors.h>

#ifndef MY_REPEATER_FEATURE
#define SKETCH_VERSION1 SV
#else
#define SKETCH_VERSION1 SV "R"
#endif

#define SKETCH_VERSION SKETCH_VERSION1 "   "

uint8_t SketchVersion[sizeof(SKETCH_VERSION)];

#define EEPROM_PARENT 0
#define EEPROM_PA_LEVEL 1

void before() {

  int8_t tmpui = loadState(EEPROM_PARENT);
  if (tmpui == 0xFF)
  {
    myParrentNodeId = 0;
  }
  else {
    myParrentNodeId = tmpui;
  }

  memcpy(SketchVersion, SKETCH_VERSION, sizeof(SKETCH_VERSION));

  tmpui = loadState(EEPROM_PA_LEVEL);
  switch (tmpui)
  {
    case 0:
      myRF24PALevel = RF24_PA_MIN;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "MIN", 3);
      break;
    case 1:
      myRF24PALevel = RF24_PA_LOW;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "LOW", 3);
      break;
    case 2:
      myRF24PALevel = RF24_PA_HIGH;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "HIG", 3);
      break;
    case 3:
      myRF24PALevel = RF24_PA_MAX;
      memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "MAX", 3);
      break;
    default:
      myRF24PALevel = RF24_PA_MAX;
      break;
  }
}

void setup()
{

}

void presentation()
{
  //Send the sensor node sketch version information to the gateway
  //sendSketchInfo("Repeater Node L1 MAX", "1.0");
  sendSketchInfo(SKETCH_NAME, SketchVersion);
}

void loop()
{
}

void receive(const MyMessage &message) {
  if (!message.isAck()) {
    if (message.type == V_VAR1) {
      uint8_t tmpui = message.getByte();
      uint8_t tmpui1 = loadState(EEPROM_PARENT);
      if (tmpui != tmpui1)
      {
        saveState(EEPROM_PARENT, tmpui);
      }
    }
    else if (message.type == V_VAR2)
    {
      uint8_t tmpui = message.getByte();
      uint8_t tmpui1 = loadState(EEPROM_PA_LEVEL);
      if (tmpui >= 0 && tmpui <= 3)
      {
        if (tmpui != tmpui1)
        {
          saveState(EEPROM_PA_LEVEL, tmpui);
        }
      }
    }
  }
}

@mfalkvidd

/**
* @brief Get transport signal report
* @param command:
* R = RSSI (if available) of incoming @ref I_SIGNAL_REPORT_REQUEST message (from last hop)
* R! = RSSI (if available) of ACK to @ref I_SIGNAL_REPORT_REVERSE message received from last hop
* S = SNR (if available) of incoming @ref I_SIGNAL_REPORT_REQUEST message (from last hop)
* S! = SNR (if available) of ACK to @ref I_SIGNAL_REPORT_REVERSE message received from last hop
* P = TX powerlevel in %
* T = TX powerlevel in dBm
* U = Uplink quality (via ACK from parent node), avg. RSSI
* @return Signal report (if report is not available, INVALID_RSSI, INVALID_SNR, INVALID_PERCENT, or INVALID_LEVEL is sent instead)
*/
int16_t transportSignalReport(const char command);

/**
* @brief Get transport signal report
* @param signalReport
* @return report
*/
int16_t transportGetSignalReport(const signalReport_t signalReport);

These functions are available only in devlopment branch. Not implemented into stable code

@mfalkvidd said in Repeatrer level limit (NRF24L01 transport):

Sending a I_SIGNAL_REPORT_REQUEST message with the command "T" could be what you need?

Unfortunately MYSController in current version doesn't support I_SIGNAL_REPORT_REQUEST message. I will try it in code, thanks

@mfalkvidd
The problem is:

My sensors network is over 30 nodes a few repeaters and so on, majority of nodes are the same hardware devices.
I want to "tune" my network changing NRF power level and MY_PARENT_NODE_ID "on th fly" (now it's "hard defined").
You've suggested to use method:

int8_t myNodeId;

#define MY_NODE_ID myNodeId

void before () { 
    // read I/O pins and set myNodeId
    myNodeId = 32;
    Serial.println( myNodeId );
}

but with MY_PARENT_NODE_ID and MY_RF24_PA_LEVEL. Good idea I will check if it working BUT:

there MUST be a way to check remotely IF it's working. There is no problem with MY_PARENT_NODE_ID because it affect network topology and it could be easily checked. I don't know how to check "from program" current power level.

Ideal solution would that sketch will detect current power level and suffix sketch name with _MIN, _LOW, _HIGH, _MAX.

It would allow me to have only two version of "HEX firmware" for OTA: with or without repeater mode. Other things (parent level and ID) I could change "on the fly" sending command" (and maybe rebooting) to sensor.

Is it clear now?

@mfalkvidd said in Repeatrer level limit (NRF24L01 transport):

@bilbolodz the level is RF24_PA_HIGH unless you have an override in your sketch.

That's obvious, I'm using it. Problem is that its "#define'ed" so value of these "variable" is set during compilation and it's not possible to change it in program!

@mfalkvidd said in Repeatrer level limit (NRF24L01 transport):

The radio object can be accessed through the global variable _radio (see here). Maybe you can just call the appropriate function?

I've made a quick grep. It looks that _radio is avaliable for RFM69 transport. For NFR there is a function RF24_setRFSetup but as parameter i takes MY_RF24_RF_SETUP defined as:

#define MY_RF24_RF_SETUP (uint8_t)( ((MY_RF24_DATARATE & 0b10 ) << 4) | ((MY_RF24_DATARATE & 0b01 ) << 3) | (MY_RF24_PA_LEVEL << 1) ) + 1 // +1 for Si24R1

It's problematic using it for power level without messing other things!

@mfalkvidd said in Repeatrer level limit (NRF24L01 transport):

@bilbolodz first question: it might be possible using the method suggested here: https://forum.mysensors.org/topic/5410/changing-node-id-at-run-time/
If you try it, please report back with the results. If it works we should document it somewhere where it is easier to find.

For sure there is possibility to change ID of node "on the fly" set:

#define MY_NODE_ID AUTO

and send message C_INTERNAL I_ID_RESPONSE with new ID node. Working even without node reboot

I will check your method with parent ID. I will try to check also these method with power level but I don't know how to check in programming way current NRF power.

@gohan said in Repeatrer level limit (NRF24L01 transport):

You could set a fixed parent ID in the repeaters so they don't try to jump one.

Is there a way to change fixed parent in "programming way (to set it as custom value in eeprom and call function setting it on startup not as define and recompile). I've about 20 devices the same type and I prefer to have the same firmware for all.

Second question (I've looked at source and answer probably is: now it's very hard to do it): Is there a way to the same with transmit power of NRF module?

I will add that these device fits near perfectly into these box:

https://www.castorama.pl/produkty/instalacja/instalacje-elektryczne/systemy-i-osprzet-instalacyjny/puszki/natynkowe/puszka-natynkowa-pawbol-klik-ip54-90-x-45-mm.html

It's Polish product so it could be hard to fine in other countries but it costs about the 1 EURO!

@gohan said in Repeatrer level limit (NRF24L01 transport):

You can chain more repeaters.

I've managed to "chain repeaters" so your statement is 100% true Still fighting with range but "there is a hope" for my project.

@gohan said in Repeatrer level limit (NRF24L01 transport):

About NRF24 power, you can also use pa_max and pa_high, it just depends on the quality of the radio module.

Even versions without PA and rubber duck antena?

Could someone please confirm that repeater mode could be "chained" (I mean that that could be more than one repeater along path between leaf node and gateway node). I've bunch of sensors but I have problems with tree mode).
Working setup for me is GW->RN->LF(RN) but I can't get working GW->RN->RN->LF.
RN - repater node
RN(LF) - repater node connected to GW or RP "last in chain
LF - leaf node (last in chain)

Second question. Generally (in most sensors) I'm using NFR24L01 modules with BCB antena (not "SMD" version, without PA). Is it OK to use RF24_PA_LOW power mode setting or for these modules only option is RF24_PA_MIN?

Best regards

Piotr

Nice plese provide BOM because it's a little unclear which MIC5365/6 should be used

OK, that's interesting data. Thanks

I've NOT played with CR2032 but with CR123 all is working fine. Of course there is HUGE difference between these batteries but maybe it's worth to try? OTA it's used not very common.

If you decide for redesigning PCB please consider adding external flash for OTA. It's very useful feature.

@Yveaux Sad to hear that.

@Yveaux said in Wireless nRF24L01+ sniffer for MySensors:

For MySensors 2.0 the sniffer will have to be updated.
Any chance for Mysensrs 2.1.1 support?

I've uploaded it on PCBs.io:

https://PCBs.io/share/zagYj

ordered but no tested yet. Cost of for PCB: 1,35 USD

I've uploaded (I hope all will be fine with PCB) on PCBs.io: https://pcbs.io/share/zZAMk
3.10 USD for 4 pieces free shipment

@gohan Seeed Studio ask 11.16 for delivery

@tbowmo How about PCBs.io? Any chance for direct link? I've trying to upload it but got an error about "Gerber normalization for Layer: Drill Holes". I'm a quite newbie for designing/uploading files for PCB factories so sorry for maybe stupid question.

Please upload it on PCBS.io and provide a direct link

Do you have suggestion how to mount RFM69 radio module? "Standard" 2.54 gold pin won't fit....

@rozpruwacz said in My Sensor node "motherboard" (MySensorsNode):

SI7021

Found it on ebay:
http://www.ebay.com/itm/SI7021-A10-GM1R-Digital-Temperature-and-Humidity-Sensor-Module-F-Arduino-Si7021-/132179773960?hash=item1ec6874a08:g:oL0AAOSw~y9ZCf9o

Still looking for good source of DMP3056L-7 or replecement

@Anticimex I've checked it but in most cases all sources you've mentioned have very expensive shipment to Poland.
How about DMP3056L-7 replacement? I've found it on aliexpres but shipment are twice such expensive as 35 pieces of transistor.

@Anticimex
Could you please:

1. Point me to drop in replacement for DMP3056L-7? It's hard to get in my area...
2. Tell where can I buy SI7021 chip?

Nice but are you sure that "security signing" is enabled? In sources I've found only
#define MY_RF24_ENABLE_ENCRYPTION

not

#define MY_SIGNING_ATSHA204
#define MY_SIGNING_REQUEST_SIGNATURES

@Boots33 I've probably found a bug in Domoticz (beta version). In Setup page I can see that Ack in ON and timeout is 1200ms but it's NOT working (values added from default during device presentation). When I turn off and the on ACK (and save) or change timeout for any other value (and save) "ack detection" start to work (I've got an error without sensor present). Thank you for your help.

@Boots33 Sensor is physically offline (no power). I've tried to "turn on" relay. On Domoticz WWW I can see that it's "on". On Mysensors GW logs I can see:

Turn ON:
mysgw: Client 1: 1;6;1;0;2;1
mysgw: !TSF:MSG:SEND,0-0-1-1,s=6,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=NACK:
mysgw: !TSF:MSG:SIGN FAIL

Turn OFF:
mysgw: Client 1: 1;6;1;0;2;0
mysgw: !TSF:MSG:SEND,0-0-1-1,s=6,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=NACK:
mysgw: !TSF:MSG:SIGN FAIL

@bilbolodz It's 1200ms so not very long

@Boots33 One more question:

In case of function:

void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);

in documentation (https://www.mysensors.org/download/sensor_api_20) I've found explanation:

"ack - Set this to true if you want destination node to send ack back to this node. Default is not to request any ack"

Does it mean "ask Domoticz to confirm that received my presentation message"?

@Boots33 What's you value for "Ack timeout"? I've 1200 (second????) so it looks for huge value! 1200 it's default.

@Boots33 I will play with these more at home.

@Boots33
About 3:
I will tell a little more. I've sensor with relays and hardware signing. For some reasons sometimes "set message" from Domoticz (via Mysensors RPI GPIO GW) doesn't reach sensor or get "signing fail" status (probably RF issues). In that case relay stays in "previous state" but Domoticz claims that's in "new state".

How to force Domoticz to NOT change displayed "state of switch" (at dashboard) when sensors fails to change state of relay?

I've set "ack for relays" at Setup->Hardware->MySensors GW (Setup)->Node->Child. Should I also enable ack in sketch during presentation for sensor (void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);)?

@Boots33 Thanks but actually these post doesn't contain answer for any from my questions.

I'd like to build sensor which answers for "request command" with value for particular sensor. I can catch these message in
void receive(const MyMessage &message) function but questions are:

1. Should I answer for these message in any "special way" or just send a message with sensor value to questioning node using bool send(MyMessage &msg, bool ack) function?
2. Is it save to use send function inside receive function or should I set flag "message to answer" and serve it "in usual way" in loop()?
3. Could someone please clarify a bit meaning of ack parameter? Sometimes I've problems with radio connectivity and I have to find the way to inform controller (Domoticz) that "set command" send to relay was accepted and executed by sensor. Does ack solve my problems?

@rozpruwacz
I've made some test. It looks that bootloader is "damaged" ONLY if sketch is loaded using programmer (USBASP in my case). If sketch is loaded via serial and bootloader all is fine. So correct usage should be:

1. Program DualOptiboot bootloader using programmer
2. Upload sketch using serial port and DualOptiboot bootloader

I've got it working BUT I've very strange "solution". I'll write it down maybe someone be able to explain me what's going on:

I've 3 versions of "test program" 1.0, 1.1, 1.2 (actually the only difference is sketch number).

1. I'm uploading manually with avrdude DualOptiboot from "Mysensors board package" (uploading using gui not working - gives strange error about fuses).
2. I'm uploading (using USBasp and Arduino GUI) program version 1.0: program is working but "Reboot" command send from MYSController gets arduin into endless loop during "boot"

0 MCO:BGN:INIT REPEATER,CP=RNORAA-,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSF:0 MCO:BGN:INIT REPEATER,CP=RNORAA-,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSF:0 MCO:BGN:INIT REPEATER,CP=RNORAA-,VER=2.1.1

1. Physical reset of board and OTA update to v 1.1 using MYSControler. OTA update is finished but at the end "endless loop"

133398 OTA:FWP:RECV B=0000
133400 OTA:FWP:FW END
136038 OTA:CRC:B=05A8,C=6506,F=6506
136040 OTA:FWP:CRC OK
0 MCO:BGN:INIT REPEATER,CP=RNORAA-,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSF:�0 MCO:BGN:INIT REPEATER,CP=RNORAA-,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSF:�0 MCO:BGN:INIT REPEATER,CP=RNORAA-,VER=2.1.1

1. Physical reset of board: still version 1.0 present and running, reboot NOT working
2. One again I program bootloader using command:

avrdude -c usbasp -p m328p -u -U flash:w:optiboot_atmega328_pro_8MHz.hex

1. Surprise, surprise: version 1.1 present and running, reboot command WORKING!
2. After these I can program freely (using OTA) other versions of program (e.x. 1.2 or even "start version" 1.0)

I'm making some STUPID mistake but I can't find it......

I've took bootloader from: https://github.com/LowPowerLab/DualOptiboot
What JEDEC ID is correct for AT25DF512C?

Could some please point me to right (working) Dualoptiboot bootloader for these board? I'm fighting with it for over two days but without success.

It's already requested feature:

https://github.com/mysensors/NodeManager/issues/73

and it will be done.

I'm trying to build sensor to drive 3 relays and connect it to Domoticz. Simple sketch:

// before
void before() {
  // setup the serial port baud rate
  Serial.begin(MY_BAUD_RATE);  
  /*
   * Register below your sensors
  */
int przek1 = nodeManager.registerSensor(SENSOR_RELAY,3);
int przek2 = nodeManager.registerSensor(SENSOR_RELAY,4);
  /*
   * Register above your sensors
  */
  nodeManager.before();
}

sensors are visible into Domoticz as switches but It's not possible to turn it on/off from Domoticz. It looks that Nodemanager expect REQ message to change state of relay but Domoticz sends SET message to change state:

RECV S=0 I=3 C=1 T=2 D=1
RECV S=0 I=3 C=1 T=2 D=0

When I've used MYSController and send C_REQ message all is working fine.

I think that in case of "output" sensors logic of getting/setting should be reversed.

I've playing with OTA using MYSController. I've noticed that sometime after OTA node upgrade or "reboot" command from MYSController node has problem with connecting to controller and finally gateway process on RPI got "Segmentation fault" and dies. Restarting gateway process won't fix it (still seg faults). Only way to get GW running is physical NODE reset.
My hardware is: RPI3 and NRF24L01+PA, decent power supply, Mysensors 2.1.1 (git clone from https://github.com/mysensors/MySensors.git). Without "OTA"/reset GW is running stable. Any ideas? I've already opened issue on github.

Logs from GW:

mysgw: Starting gateway...
mysgw: Protocol version - 2.1.1
mysgw: MCO:BGN:INIT GW,CP=RNNG-SQ,VER=2.1.1
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: TSM:INIT:TSP OK
mysgw: TSM:INIT:GW MODE
mysgw: TSM:READY:ID=0,PAR=0,DIS=0
mysgw: MCO:REG:NOT NEEDED
mysgw: Listening for connections on 0.0.0.0:5003
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
Segmentation fault

It's not quite clear for my how to use MYSBootloader for OTA. I'm running Domoticz as a controller (on RPI) and my gateway also is running on RPI (NRF on GPIO). Should have I one more arduino gateway connected to Windows machine running MYSController? As far I know there could be only one gateway in mysensors network.

@user2684 Yes, that could be nice solution.

@user2684 said in NodeManager: plugin for a rapid development of battery-powered sensors:

In this way the same device address will always get the same child id and if a sensor will be unavailable, it will not mess up the other child IDs. Is this something which can be done or am I missing something? Far from saying it is elegant of course...

Of course that it's solution but hardcoding addresses into sketch as you said "it's far from elegant"..... The good idea (in my opinion) is to put addresses into array stored in eeprom. The ideal solution would be to have possibility put addresses into eeprom by mysensors controller

@user2684 said in NodeManager: plugin for a rapid development of battery-powered sensors:

This is available for all the sensors. So in the case of multiple DS18B20 you need to register them all in the usual way ( registerSensor(SENSOR_DS18B20,pin)) then assign the child id you like just after so in case one is lost, you still have a static mapping. The alternative would have been to provide a special registerSensor only for DS18B20 which I don't like that much. Any other better alternative of course is more than welcome!

Thanks for support but actually in case of multiple DS18B20 your "general solution" is not very useful..... It require manual checking ID (first it IDs need to bs stored in EEPROM) renaming child id sensor in case of change and so on. In my private opinion it could be better add special registerSensor() function which takes pin and DS18B20 ID and register sensor (or not). Please consider these.

I'm trying to start play with ATSHA204A signing. I've ATSHA204A-SSHCZ-T chip (8-lead SOIC single wire). I've connected chip pins: 4 - GND, 8 - VCC (5v), 5 - A3, I've added 100nF between 4 and 8 and 4K7 resistor between 5 and 8. I've loaded "near clear" SecurityPersonalizer sketch (only added #define MY_SIGNING_ATSHA204_PIN A3 #define MY_SIGNING_ATSHA204) but I've got:

Personalization sketch for MySensors usage.

Failed to wake device. Response: E7
Halting!

any ideas?

@user2684 Great, so I'm waiting for version 1.4. Any ideas about timeline?

@user2684 said in NodeManager: plugin for a rapid development of battery-powered sensors:

@bilbolodz multiple DS18B20 are supported indeed, when you register a DS18B20 sensor and provide the pin where multiple devices are attached, NodeManager will go through all of them (by calling getDeviceCount() of DallasTemperature) and will register each of them with a different child id. Is this what you were looking for?

Multiple sensors: great but for me important thing is "fixed" matching exact DS18B20 to particular child id. I'm going to monitor may two function water boiler and check input/output temperature. In case when one of the DS disappear (because of many reasons) after next nodemanager device startup assigning sensors to child id will change and it will be a great problem. That's why I'm asking for exact assigning DS id - child id. Is it clear now?

@Robbie_ said in NodeManager: plugin for a rapid development of battery-powered sensors:
Try this:

nodeManager.setPowerPins(6,7,10000);
wait(10000);
nodeManager.registerSensor(SENSOR_DHT22,3);```

@Robbie_ I've NOT checked anything but I think that probably better:

1. power up DHT
2. wait a little to "dht startup"
3. register sensor

@user2684 Great plugin, thanks. Please: consider adding support for a more than one DS18B20 devices and fixed mapping sensor_id <-> DS18B20 id.

Just to be sure: SOFT_HMAC_KEY, SOFT_SERIAL is used for signing, AES_KEY is used for encryption. SOFT_HMAC_KEY, AES_KEY should be the same across all network nodes, SOFT_SERIAL should be different for every node?

@AWI I've made similar project but using RS485 and modbus for communication. Now I'm porting it into mysensors. In my project I've light sensor to lower fan revs during night (because of noise). I will try to post my sketch when I finish it.

Now I've read some post on these forum and found very important statement:

Automatic node assignment is handled by the controller (see https://www.mysensors.org/about/network for information about the different components in a MySensors network)

I've playing with GW without controller running (Domoticz) I've to check it today.

@user2684 I've exactly the same problem.
I've noticed that putting #define MY_NODE_ID X (not AUTO) makes situation better (a little).
I've also played with MY_RF24_PA_LEVEL settings and "MAX" is NOT working for me (MIN, LOW, HIGH are fine but without AUTO id number).
I've plan to move GW to arduinoMega and ethernet but a few post above there is a report that "it's also not working!"......
Does really (USB) serial gateway the only way for RPI????

How about dimming? Due to lack of "zero crossing detection" it could be a problem!