Posts made by robosensor

Is it OK?

https://www.virustotal.com/#/file/6082b86e6a56783e692afaa7c6d79e5af0d6ca58476ef7e180a39594ce441cd7/detection

No such warnings/detections for .282 version.

You can try also Bosch BME280 - all in one sensor for temperature, humidity and pressure

Ikea is also producing zigbee-compatible smart home components (TRÅDFRI series), including led lighting, dimmers, PIRs, ethernet gateways without cloud-based parts (can work w/o internet).

Starting from $11-$19 for dimmers/PIRs here in Poland.

Seems like this is offtopic, but there are good meanwell power supplies designed to run 24x7, like this:

http://www.meanwell.com/webapp/product/search.aspx?prod=DR-15 (MTBF 1.1M hours)

Or even something like this:
http://www.meanwell.com/webapp/product/search.aspx?prod=PM-05 (MTBF 1.5M hours) and so on

I used long time this NFM-05-5 power supplies, very good, no problems at all:
http://www.meanwell.com/webapp/product/search.aspx?prod=NFM-05

@NeverDie you can just google for images for "exploded/burned phone charger"

Just an example:

If safety is on the first place you can make your own power supply using miniature transformers like this (lower half of PCB):

Such transformers are very small for low-power nodes:

UPD: link to the topic: https://forum.mysensors.org/topic/6259/encapsulated-transformers-instead-of-traditional-switching-power-supplies-like-hi-link

Good ruler, I have such ruler too

Today's power part of my RGBW dimmer node (four LED channel PWM inputs, 12V input, +12V sense, +5V, +3.3V outputs). Dimmer is controlled by MySensors and also by conventional Samsung TV remote control (five presets, ability to record color presets, autofade from one preset to another, control of each LED channel brightness, gamma correction and so on).

Try to call Serial.flush(); after each print line, this ensures that all data sent to serial port before next line executed.
Can you post image with connection wires to DS18B20 sensor? Could the problem be that this chip is a fake?

Power (lower half) and external interfaces (upper half) PCB for my "entrance" MySensors node (unregulated voltage, +5V, +3.3V, doorbell detector, electronic door lock status, temperature, etc). I'm using conventional 220V=>6V transformers as main power supply and as simple 220V presence detector for doorbell.

Simple RS485 gateway and node for two BME280 sensors:

Returns true if message reached the first stop on its way to destination

What will be returned in the case of NRF24L01 as gateway's receiver at destination and internal nrf24 buffer is already contains 3 unread messages?

Hello.

How I can change default RX/TX LED blink behavior without modifying MySensors library? I'm talking about serial gateway. Gateway always blink RX and TX LEDs together just because gateway receives (RX) data from serial port and immediately sends (TX) this data to radio network. The same problem happens then gateway receives data from radio.

I just want to blink RX led then something received from radio network and blink TX led then something sent to radio network.

	if ((INDICATION_TX == ind) || (INDICATION_GW_TX == ind)) {
		ledsBlinkTx(1);
	} else
#endif
#if defined(MY_DEFAULT_RX_LED_PIN)
		if ((INDICATION_RX == ind) || (INDICATION_GW_RX == ind)) {
			ledsBlinkRx(1);
		} else
#endif

@rvendrame said in 3.3 or 5v tranformer for mysensors projects:

On the other hand I see the bigger footprint as well as more components to assembly.

Bigger, but not always. For low-power nodes you can use very small transformers, size of such transformers with rectifier and voltage regulator comparable to Hi-Link PSUs with external curcuity, just an example on my finger:

@m26872 said in Encapsulated transformers instead of traditional switching power supplies like Hi-Link:

for me the sunny season is too short.

I havn't yet tried to use solar batteries in winter so maybe I have the same problems (despite the fact that I'm living 3 degrees south of you), but I have backup solution for very cloudy winter days - regular battery charger.

@m26872 thank you, great review! As far as I understand, no-load power usage is 0.57W (or 1.05W?) vs 1.87W (for small) or 1.76W (for big transformer).

So up to three times more no-load power usage for regular transformers. But in any case overall power usage is still acceptable for me because I sleep better with such transformers

Now I'm moving to solar-powered sensor nodes where it's possible.

If safety comes first you may be interested in these transformers: https://forum.mysensors.org/topic/6259/encapsulated-transformers-instead-of-traditional-switching-power-supplies-like-hi-link

I'm using such non-electronic transformers and I'm happy.

Yet another version and first test results.

Now I'm able to screw panels together using any side:

I connected solar panels together (parallel connection, but each panel in series with it's own shottky diode). 11 panels on north side (direct sunlight from about 06:30 up to 09:00) and 5 panels on south side (direct sunlight from about 12:00 up to 19:00). Panels located on window-sill outside of house.

On south side I'm using 6V AGM VRLA acid battery (as far as I remember 4.5 Ah), on north side battery is the same, but battery capacity is 1.3 Ah.

At first I connected panels directly to batteries (panels open-circuit volage is about 6.8-7.5 volts), but I got weird results. When it's sunny and the sky is clear batteries are charging very slowly and then it's cloudy - batteries are charging faster. Scattering of light by clouds?

Then I connected solar panels to step up regulators (mt3608 as far as I remember, output set to 7.0 volts), now I'm getting very good results. Both batteries are charging almost all the day.

Graphs showing step up output voltage (connected directly to battery):

Again, then weather is cloudy batteries are charning a little better.

Also it seems that I have connected too many batteries. It's necessary to try only 1-2 batteries on each side.

Now I'm using simple voltage reporting sketch (5V arduino pro mini, report voltage and smartSleep() every 10 seconds), battery connected directly to RAW pin of arduino. Nothing is changed on hardware and software sides except I removed power led. NRF24L01 using it's own AMS1117-3.3 regulator (consumes a lot of current, about 2mA) connected directly to battery.

Can I use hwCPUVoltage() function to read cpu power supply voltage in my sketch? As far as I understand this function is not documented.

I'm asking because this function affects analogReference(INTERNAL) with further analogRead(pin) call. According to source code it seems for me that hwCPUVoltage() isn't restoring ADC settings before return.

Simple code to test is looking something like this:

void setup()
{
    analogReference(INTERNAL);
}

void loop()
{
    analogRead(pin_number); // good value
    hwCPUVoltage();
    analogRead(pin_number); // bad value
}

I just published, maybe someone will be interested.

Simple and lightweight 3D-printed solar panel housing for 60x110 mm sized panels widely available on Chinese shops. Three holes on every side for fixing housing allow to fix it in any position/angle. The same holes used to fix solar panel itself in housing.

I'm using cheap ($1/piece) Chinese solar panels.

http://www.thingiverse.com/thing:2303029

0_1494200102051_SolarHousing2.stl
0_1494200114033_SolarHousing v2.step

Please try to test code with wait() between each send. In some enviroments (not in all) sometimes (not always) ESP code blocks thread of execution up to 200 milliseconds while waiting for TCP ACK packet. So if you send next your packet in this 200 ms interval packet (or next packet) can be missed.

How many packets per second are you sending to ESP side?

@tekka haven't yet tried other hardware (but I want to try). I'm using five nodes at this moment with the same arduino nano boards (the same supplier, seems like the same batch). As far as I remember there was another node with the same behavior, but I somehow fixed the problem and I do not remember what I did for this, maybe I just replaced that nano board. So now I have the only node with such behavior.

I have nano boards from another supplier (with usb-micro instead of usb-mini), I can try them. But most likely that I just have fake chips.

Also about power. Node in it's usual place using high-quality MeanWell NFM-10-5 power supply (5V connected directly to Nano pins + capacitor (220 or 330 uF, don't remember). Today I used Korad KA3005D power supply (12V, connected to RAW pin, Nano contains AMS1117-5.0 regulator).

As for logs from MYSController, node starts sending firmware config messages every 2 seconds:

135	12.03.2017 17:36:32	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101
136	12.03.2017 17:36:34	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101
137	12.03.2017 17:36:36	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101
138	12.03.2017 17:36:38	RX	1 - LCD Node	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	32000E00B005C92B0101


1393	12.03.2017 18:35:09	RX	4 - AirServo	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	46000200B00394200101
1394	12.03.2017 18:35:11	RX	4 - AirServo	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	46000200B00394200101
1395	12.03.2017 18:35:13	RX	4 - AirServo	INTERNAL	C_STREAM	NO	ST_FIRMWARE_CONFIG_REQUEST	46000200B00394200101

P.S. After firmware update node changed it's ID from 1 to 4 and I could not change this using MYSController (node ID is defined in source code, I'm using static node IDs). I have tried to change ID and to erase eeprom, without success.

@tekka

1. I have uploaded firmware using OTA (MYSController 1.0 build 3314, MYSBootloader 1.1).
2. After this I powered off and powered on several times my node.
3. I downloaded firmware from atmega328p back to my computer into file1.hex
4. After this I powered off and powered on several times my node.
5. I downloaded firmware from atmega328p back to my computer into file2.hex
6. After this I powered off and powered on several times my node.
7. I downloaded firmware from atmega328p back to my computer into file3.hex
8. After this I powered off and powered on several times my node.
9. I downloaded firmware from atmega328p back to my computer into file4.hex
10. After this I powered off and powered on several times my node.
11. I downloaded firmware from atmega328p back to my computer into file5.hex

After this I compared all files. I use TortoiseMerge. I'm aware of format of Intel hex files (length, address, type, data, checksum).

Differences between file1 and file2: 128 bytes of memory (4 lines in hex file, each line 20 bytes (data bytes) long, I mean raw data without headers, address, type and checksum fields) starting at 0x1500 memory position are different. First file contain valid (looks like valid) data, second file contain 128 bytes of 0xFF at the same memory position.

Differences between file2 and file3: 128 bytes of memory starting from 0x0180 memory position. file2 contain valid data, file3 contain 128 bytes of 0xFF.

Files file3 and file4 is the same, no differences at all.

Differences between file4 and file5: 128 bytes of memory starting from 0x2C80 memory position. file4 contain valid data, file5 contain 128 bytes of 0xFF.

So file5 (relative to file1) contain three bad blocks filled with 0xFF, each block is 128 bytes long.

So almost each start new 128-byte bad block appears in random place (in addition to already existing bad blocks).

Bad blocks looks like this:

:20018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7F
:2001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5F
:2001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3F
:2001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F

I hope that I explain this issue without uploading files.

@pacovi said in Mysbootloader, problem after reboting.:

I've been able to upload several FW's (repeater, temperatures relay, etc.) Everything works fine for several days, but when I switch off the node for some minutes, and then switch on again, the node start requesting firmware in a loop, I'm not able to upload any FW or to reboot the node from MYSController.

Sorry for reply in 'expired' topic. Just found what is happening. One of my nodes (Chinese Arduino Nano board, 5V atmega328p) always starts to flood controller with firmware request messages after few minutes (sometimes hours or days) of uptime.

I used "avrdude.exe" -C"avrdude.conf" -v -patmega328p -cusbasp -Pusb -b19200 -Uflash:r:firmware.hex:i command to download firmware from atmega chip back to my computer and found that every few boots firmware loosing 128-byte blocks of data in random places. Broken blocks are filled with 0xFFs (like erased flash area).
Few examples of memory positions of bad blocks: 0x0180, 0x1500, 0x2C80. I've never seen broken blocks in bootloader code.

I'm using MYSBootloader V1.1 by @tekka

I do not know who is to blame for this, most likely fake Chinese atmega328p chips. Or bootloader/firmware can corrupt flash memory?

@gohan you are right, somebody can use such transformers as heaters

Yes, transformers are not very efficient, but overall power usage is acceptable at least for me. But what about other things such as safety, galvanic isolation, reliability, high frequency noise, Y-capacitors between high-voltage and low-voltage sides, the need to add external circuitry (varistors, fuses, etc) for switching PSUs and so on?

Somebody tried to measure no-load current at 230V side of switching PSUs like Hi-Link? And PSU temperature at low loads?

@gohan 8.3 mA AC at no load, 8.4 mA AC at load (~40 mA DC at low-voltage side), 11.2 mA AC at secondary winding short circuit. 225 V AC mains voltage. About 1.87 VA (~1.35 kW*h per month?) according to my calculations for enviroment heating. Primary winding resistance 6.47 kOhm.

Also I have tried second (slightly bigger, but 3 times more powerful, green on my photos) 1.5VA transformer. 7.8 mA at no load, 30.0 mA at secondary winding short circuit. 13.1 V AC no load voltage at secondary winding. Primary winding resistance is 3.32 kOhm. After 10 minutes of work without load transformer is much colder than the smaller one. Fingers do not feel much difference in temperature between the table and the transformer.

I'm using cheap Chinese DT9208A multimeter.

@gohan I don't know how to compare efficiency of such different devices.

According to http://lygte-info.dk/review/Power Mains to 5V 0.6A Hi-Link HLK-PM01 UK.html maximum efficiency of Hi-Link is about 70%, but efficiency decreases at low currents down to 40-50%.

If you want I can measure current in input winding (230V) of transformer with load and without load.

So, as I promised, I'm providing test results of smaller one transformer (6V 0.5VA).

Transfomer output is around 10.0 volts (AC) without load, rectified voltage is about 14.3 volts, DC (IN5819 shottky diode bridge, 16V 220uF capacitor).

Under load (LM7805 + second 220uF capacitor + Arduino Nano with BME280 sensor and NRF24L01 radio, reporting three values (humidity, pressure, temperature) every second, without deep sleep modes) current usage before LM7805 is around 40 mA (I have no oscilloscope, multimeter only), alternating voltage on transformer output under load is around 7.9 AC volts, rectified voltage is around 8.4 DC volts.

Transformer (both without load and with load) is a little hot, a little warmer than the human body (maybe around 40 degrees C).

Test node working great without any issues.

Size of IN5819 rectifier bridge, two capacitors and LM7805 with transformer is comparable with Hi-Link PSU.

I think this is very good solution (safety first) for low-power nodes, including in-wall nodes and so on.

@rvendrame transformers often contain two 115V windings (but not the ones that I bought), so you can connect one of them to use in 110V environment or connect both windings in series to use in 220V environment.

As for time and assembly size - yes, you are right, but for low power devices it's possible to use very small rectifier bridges (or just two sot-23 two-diode assemblies), and small sot-23 LDO (for examle, very popular XC6206P332MR - 662K). So all them with capacitor(s) will be almost the same size on PCB as well-known Hi-Link switching power supply.

Also, for switching power supples you need external circuits (fuses, varistors, etc), just first two links with example of Hi-Link usage in real world:
https://www.openhardware.io/view/77/AC-DC-double-solid-state-relay-module
https://www.openhardware.io/view/334/MySensors-RFM69W-relay-actuator-node

On the other hand, for such small low-power transformers even shortage of secondary winding will not result in problems, this will just slightly heat up transformer.

Just bought yesterday in our local store two types of small transformers:
13 PLN ($3.18) - 0,5W 230V => 6V 0,083A, 18,5 x 21,5 x 22,5 mm very small
10.5 PLN ($2.57) - 1,5W 230V => 9V 0,16A , 22 x 32 x 27 mm slightly larger

I will try/test transformers in the next few days.

Has anyone tried to use small transformers for PCB mount like this as power supplies?

$2.09 without shipping costs, AC 6V voltage, 58 mA: https://www.aliexpress.com/item/PE2006-M-Power-0-35VA-220V-6V-Expory-resign-encapsulated-safety-isolating-transformer/32688201552.html

This transformer suits low-power nodes. There is a lot of models for different power requirements.

Transformers are very small (22x23x15 mm, comparable to commonly used HLK-PM01 - 15x34x20 mm), but it's requied to use rectifier, capacitor and linear regulator.

As for me such transformers are much safer (fire-proof, reliability, safety - full galvanic isolation) then using 24x7 instead of switching power supplies. UPD: Also such power supplies produces much lower high frequency electromagnetic noise.

What are advantages and disadvantages of using such transformers?

Maybe someone tried slightly more smart way of sending presentation messages instead of using delay? Can we use bool ack param of present() function to check delivery and send next (or resend current) only after we have received delivery report?

Somebody tried to connect blynk to MySensors? Blynk have awesome highly configurable GUI:

https://play.google.com/store/apps/details?id=cc.blynk

Have you tried BME280 sensors? It seems for me that single BME280 sensor can substitute this sensors list:

DS18B20 (temperature sensor)
DHT11 (humidity sensor)
Si7021 (humidity sensor)
BMP180 (pressure sensor)

Is there any chances that binary protocol will support sending of multiple sensor values per one message?

I'm talking about nodes that (for example) sending several binary switch sensor values with 1-byte value. Even if one set/req message contains 5 fields (5 bytes, currently Sensor id, Var type, Ack-thing (request ack / is ack), Payload type (integer, float, string, binary), Payload) it's possible to pack at least 4-5 results into single 32-byte message. This will reduce the load on the radio network 5 times. Also this will reduce gateway's load. It's also possible to remove duplicating fields and further reduce protocol.

For example, some of my nodes sending 5 temperatures from ds18b20 sensors. Packing all 5 temps into single message (2 bytes for temp and 1 byte for sensor id) will reduce traffic 5 times.

Packing/unpacking can be done at gateway side.

Does anyone know how to allow multiple TCP connections forwarded to one MYS tty port? This socat command blocks second TCP connection until first one disconnected.

I just want to connect MYSController using TCP without disconnecting my custom MQTT<=>serial controller script. I'm using RPi with USB-serial gateway.

P.S. @tekka is there any chances that MQTT access will be implemented in MYSController?

@techRH said:

$ sudo socat tcp-l:5003,reuseaddr,fork file:/dev/mySensorsCOM,nonblock,waitlock=/var/run/mySensorsCOM.lock

@hek is it possible to add middle click or ctrl+left click handler to this page? https://www.openhardware.io/explore

I'm using Firefox and it's impossible to open projects from this page in new browser tabs. Both mouse middle click and CTRL+left click isn't working. First one just scrolls browser window, second one opens project in the same tab instead of opening in new tab. Also it's impossible to right click on project preview image to select "Open Link in New Window" context menu item.

The same thing in Microsoft Edge browser.

It's my code

I changed this method from private to public, this function is used to determine wait time needed for right non-blocking wait call. Seems like I should make PR to original library instead of modifying MYS copy.

Not sure I'm doing this right way, but changing this line:

        fh => $serialDevice->{'HANDLE'},

to this line

        fh => new_from_fd IO::Handle ($serialDevice->{FD}, "w"),

Fixed Filehandle GEN0 opened only for input bug for me on RPi 2. Fix works because of $serialDevice->{'HANDLE'} is opened as read only in SerialDevice and should not be used for write:

    # a handle object for ioctls: read-only ok
    $self->{HANDLE} = new_from_fd IO::Handle ($self->{FD}, "r");

Also it is possible to partially solve this issue by fetching all available messages from NRF24 FIFO and concatenating them into one TCP packet for ESP. It is possible that this will be useful for other gateways too.

@Yveaux said:

IMHO it really is time to investigate the impact on the library to support message queueing (fetched & sent from interrupt).

But no chances that MYS protocol will be changed? I'm talking about reliable delivery and message ids. That topic is very close to this.

The problem is slightly wider than it seems. Wireless messages should be fetched from internal NRF24 FIFO and stored into memory as soon as possible (using interrupts?). But lack of RAM makes the problem difficult to be solved.

The same thing happens not only with ESP8266 gateway and TCP ACKs, but also with all blocking calls during sensor reading (for example for old blocking call to read DS18B20 data with 750ms delay), with improper use of delay() instead of gw.wait() and so on.

ESP8266 gateway is quite unusable in setups where TCP ACKs can be delayed. This is because thread is blocked until TCP ACK received in ESP wifi code. So all wireless messages will be rejected if NRF24 receives more than 3 messages during this 200ms delay: http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors/235

@hek, is it possible to search for projects that I can buy? It would be great to have such filter.

@Koresh what about price for assembled boards?

@mfalkvidd yes, I understand that this feature will break everything.

Also, message id field can help to filter out duplicate messages on receiving side (due to message acknowledgement is not received by sending side) and can help to re-order incoming messages in right way using increasing message ids.

Even more, sending acknowledgement with only numeric id instead of full message data can help to remove load from MCU (need to parse full message), from RAM (need to store full message), and from 'network' (both wired and wireless, data channel will be busy less time).

@mfalkvidd for example, to know last actuator state.

Imagine that you are sending three commands:

1. ON
2. OFF
3. ON

Then you receive two confirmations: ON and OFF. For which one ON ack is received? Is current actuator state after receiving two confirmations ON or OFF? How to determine which message (first or third) is lost and what you need to resend?

Seems like it is impossible now to distinguish for which message we have received acknowledgement. For example, when you just sent two identical messages. Message should contain message ID field (also called packet id or sequence id, unique for sending side) either in protocol headers (need to change protocol and break compatibility) or in user-defined message body (also breaks compatibility).

@Jan-Gatzke said:

@robosensor Have you tried to enable the ibternal pullup for the pin?

Didn't read biss0001 datasheet, so I don't know is output pin 5V-compatible (for pullup) or not, so I didn't tried to enable internal pullup.

In any case I will try to check what happens with OUT pin of module during this 1/0 flood.

The same problem for me. Different HC-SR501 sensors (connected to one of three nodes with this sensors) periodically entering "flood mode" with continuous sending 1/0 values. I suspect that this is power supply related problems.

Please also escape all information that demo user enters Just an example: I entered html in forecast sensor data in dashboard and this html is rendered in resources/logs section: http://demo.mycontroller.org/#/resources/logs/

The same thing in node names in groups: http://demo.mycontroller.org/#/resources/groups/map/list/1

Sorry, seems like I broken demo site by entering " ` " in temperature field of sensor

Now getVariables returns 500 error with message:

errorMessage:"java.lang.NumberFormatException: For input string: "`""

@hek, I suspect that there is something wrong with this pull request. If you just returning true, then protocolParse() will not be called and gatewayTransportReceive() function in MyGatewayTransport.cpp will receive previously parsed message.

Subscribing to the topic, seems like I have the same problems with one of my nodes. If I power off and power on again my node after few days of online, node just start flooding gateway with messages like this:

1451044164;1;255;4;0;0;32000B00F004D4A80101
1451044166;1;255;4;0;0;32000B00F004D4A80101
1451044168;1;255;4;0;0;32000B00F004D4A80101

I'm not able upload any FW or reboot node too. Only reflash of bootloader using ISP 6-pin connector helps me.

@mickaelh51 thank you very much for test results! Where is openhab located? Raspberry Pi? Or PC?

@mickaelh51 I'm sorry, MQTT gateway is slightly different.

Please replace function in file MyGatewayTransportMQTTClient.cpp

bool gatewayTransportSend(MyMessage &message) {
	if (!_client.connected())
		return false;
	snprintf_P(_fmtBuffer, MY_GATEWAY_MAX_SEND_LENGTH, PSTR(MY_MQTT_PUBLISH_TOPIC_PREFIX "/%d/%d/%d/%d/%d"), message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type);
	debug(PSTR("Sending message on topic: %s\n"), _fmtBuffer);
	return _client.publish(_fmtBuffer, message.getString(_convBuffer));
}

With something like this:

bool gatewayTransportSend(MyMessage &message) {
	if (!_client.connected())
		return false;
	snprintf_P(_fmtBuffer, MY_GATEWAY_MAX_SEND_LENGTH, PSTR(MY_MQTT_PUBLISH_TOPIC_PREFIX "/%d/%d/%d/%d/%d"), message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type);
	debug(PSTR("Sending message on topic: %s\n"), _fmtBuffer);

	unsigned long start_time = hwMillis();
	bool bReturnValue = _client.publish(_fmtBuffer, message.getString(_convBuffer));
	debug(PSTR("Ethernet transaction time: %u ms\n"), hwMillis() - start_time);
	return bReturnValue;
}

I just want to know speed of _client.publish() call, but I don't have W5100.

@mickaelh51 can you check speed of _ethernetServer.write(_ethernetMsg); call using the same debug code as for esp8266 gateway code here: http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors/225 ?

Something like this:

        // Send message to connected clients
        #if defined(MY_GATEWAY_ESP8266)
            for (uint8_t i = 0; i < ARRAY_SIZE(clients); i++)
            {
                if (clients[i] && clients[i].connected())
                {
                    clients[i].write((uint8_t*)_ethernetMsg, strlen(_ethernetMsg));
                }
            }
        #else
            unsigned long start_time = hwMillis();
            _ethernetServer.write(_ethernetMsg);
            debug(PSTR("Ethernet transaction time: %u ms\n"), hwMillis() - start_time);
        #endif

File to patch is libraries\MySensors\Core\MyGatewayTransportEthernet.cpp

@balloonguy just tried this link. Everything is working, MYSController.zip file with md5 checksum dfe98f9e7ed6e1c3d5c418a862c23ee0 is downloaded.

@Yveaux said:

So another confirmation of what we knew already.

Yes. It seems that I now understand what is happening. WiFiClient::write() blocks thread until TCP ACK packet received or until timeout (5 seconds). Windows sending TCP ACKs after 200ms timeout. That's why write() delayed for ~200 milliseconds for windows-based controller. More information (and link to non-blocking library) is available here: https://github.com/esp8266/Arduino/issues/922

Do you know how many nRF messages are actually sent during this wifi write call?
The nRF has a rx buffer for 3 messages -- not sure if MySensors uses all 3 of them.

Nodes sending 3-7 (sometimes more) messages with 35 ms delay between messages, so in my case 3-packet hardware buffer in nrf24 is overflowed after 105-140 milliseconds of write() call.

Also disconnection of client during clients[i].write() call causes reboot by watchdog
I guess this is ESP core related. Is this fixed in code 2.0.0?

I did not tried to check this reboots in 2.0.0, but 2.0.0 is much more stable and I never seen any reboots/resets.

Just tried old version of esp8266 libraries (1.6.5-947-g39819f0 instead of 2.0.0) with old version of esp8266 gateway (master branch, commit 9ef2604c81d2fea5d646a9a194f312192833a79b) and got exactly the same results.

WiFi write() time is about 150-200 milliseconds for remote server in another country, 200-210 milliseconds for windows7-based computer in local area network and 0-4 milliseconds for Raspberry Pi 2 in local area network.

To show transaction times just replace original output function in Esp8266Gateway.ino with following code:

void output(const char *fmt, ... )
{
  char serialBuffer[MAX_SEND_LENGTH];
  va_list args;
  va_start (args, fmt );
  vsnprintf_P(serialBuffer, MAX_SEND_LENGTH, fmt, args);
  va_end (args);
  Serial.print(serialBuffer);

  unsigned long start_time = millis();
  
  for (uint8_t i = 0; i < ARRAY_SIZE(clients); i++)
  {
    if (clients[i] && clients[i].connected())
    {
//       Serial.print("Client "); Serial.print(i); Serial.println(" write");
       clients[i].write((uint8_t*)serialBuffer, strlen(serialBuffer));
    }
  }
  
  start_time = millis() - start_time;
  Serial.print("WiFi transaction time: "); Serial.print(start_time); Serial.println("");
}

Also disconnection of client during clients[i].write() call causes reboot by watchdog:

 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1264, room 16 
tail 0
chksum 0x42
csum 0x42
~ld

Yes, loosing messages due to slow esp8266 network code.

http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors/224

http://forum.mysensors.org/topic/2637/why-mysensors-isn-t-using-interrupts-for-nrf24

@Oitzu I'm experiencing the same problems as @Fabien with packet loss in esp8266-nrf24 gateway. I'm sure this is not hardware setup problem, this is software problem existing only in some cases.

http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors/224

@Oitzu sorry, I'm not very familiar with the internal structure of the MySensors code, so I have not yet tried to change anything and just asking. Developers decided not to use interrupts, apparently, they had some reasons. That's why I'm asking.

For example, atmega328 contains enough memory to hold ring buffer for 5-10 messages, so I think it possible to just store received packets for slow-processed messages into buffer in interrupt routine and process this buffered data in usual way.

Seems like RPi+nrf24 gateway code may be rewritten in near future using interrupts?

Sensor nodes in some situations can lost messages due to blocking call to old version of ds18b20 code, sleep calls, working with slow hardware and so on. Gateways in some situations (esp8266) lost messages due to blocking call to network functions.

Why MySensors is not using interrupts for nrf24? Why MYS code is constantly polling nrf24 via SPI instead of just waiting for interrupt from nrf24? There are some difficulties with the implementation of interrupt-based model?

@petewill every 425 seconds your door sensors will be blind up to 750 ms because of you using blocking call to dallasTemp.requestTemperatures(). It is very unlikely that this will happen, but it can be Safer way is to use non-blocking access to dallas sensors: https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/DallasTemperatureSensor/DallasTemperatureSensor.ino

@Yveaux I completely agree with you. Rewriting gateway code to support interrupts is not very easy task and it is not clear what problems you will encounter. Furthermore, rewriting will not solve the problem of delays, this only can solve packet loss problem.

Just tried to connect from RPi 2 (connected using WiFi directly to router), average delay is 2-5 milliseconds, sometimes 5-10 ms. Seems like this is good temporary solution.

@Yveaux seems like delays caused by low-level network/tcp code or settings of receiving side (maybe something as TCP ACK packet delays or Nagle algorithm or something like this).

ESP8266 connected directly to Mikrotik RB2011 router.

Then I connect from external server (ping to server is about 55 milliseconds, FreeBSD 9.3, Perl), delays about 140 milliseconds.
Then I connect from windows-based computer, connected directly to router, delays about 200 milliseconds (both windows telnet and PuTTy).
For 2 parallel above connections delays about 350 milliseconds.

Then I connect from router's internal telnet client, delays about 1-2 milliseconds
Then I connect from android-based phone (phone connected to router via wifi, using ConnectBot software), delays vary from 3-5 milliseconds (mostly) to 100-150 milliseconds (less frequently).

Seems like interrupts for nrf24 is the only solution. Seems like esp8266 gateway with such delays is completely unusable with high packet rates. With ~150 milliseconds delays no more than 6 messages/second packet rate allowed.

Just to reference: I'm using Arduino 1.6.5 with esp8266 libraries version 2.0.0 installed.

I think I found problem. As I said before, seems like WiFi's clients[i].write() call blocks thread for a very long time.

I added logging of write() time:

		// Send message to connected clients
		#if defined(MY_GATEWAY_ESP8266)
			unsigned long start_time = hwMillis();
			for (uint8_t i = 0; i < ARRAY_SIZE(clients); i++)
			{
				if (clients[i] && clients[i].connected())
				{
					clients[i].write((uint8_t*)_ethernetMsg, strlen(_ethernetMsg));
				}
			}
			debug(PSTR("WiFi transaction time: %u ms\n"), hwMillis() - start_time);
		#else
			_ethernetServer.write(_ethernetMsg);
		#endif

And got following results:
For Perl script from FreeBSD server in another country (ping to server is about 55 milliseconds):

0;0;3;0;9;WiFi transaction time: 141 ms
0;0;3;0;9;read: 2-2-0 s=1,c=1,t=23,pt=2,l=2,sg=0:98
0;0;3;0;9;WiFi transaction time: 141 ms
0;0;3;0;9;read: 2-2-0 s=6,c=1,t=43,pt=3,l=2,sg=0:2
0;0;3;0;9;WiFi transaction time: 140 ms
0;0;3;0;9;read: 1-1-0 s=105,c=1,t=0,pt=7,l=5,sg=0:27.5000
0;0;3;0;9;WiFi transaction time: 136 ms
0;0;3;0;9;read: 1-1-0 s=106,c=1,t=0,pt=7,l=5,sg=0:52.8750
0;0;3;0;9;WiFi transaction time: 140 ms
0;0;3;0;9;read: 1-1-0 s=107,c=1,t=0,pt=7,l=5,sg=0:45.9375
0;0;3;0;9;WiFi transaction time: 142 ms
0;0;3;0;9;read: 1-1-0 s=108,c=1,t=0,pt=7,l=5,sg=0:34.4375
0;0;3;0;9;WiFi transaction time: 137 ms
0;0;3;0;9;read: 1-1-0 s=1,c=1,t=16,pt=0,l=1,sg=0:0
0;0;3;0;9;WiFi transaction time: 143 ms

Connection from LAN (windows telnet client):

0;0;3;0;9;read: 3-3-0 s=1,c=1,t=23,pt=2,l=2,sg=0:61
0;0;3;0;9;WiFi transaction time: 209 ms
0;0;3;0;9;read: 4-4-0 s=1,c=1,t=24,pt=2,l=2,sg=0:152
0;0;3;0;9;WiFi transaction time: 201 ms
0;0;3;0;9;read: 4-4-0 s=2,c=1,t=24,pt=2,l=2,sg=0:43
0;0;3;0;9;WiFi transaction time: 212 ms
0;0;3;0;9;read: 4-4-0 s=3,c=1,t=24,pt=2,l=2,sg=0:129
0;0;3;0;9;WiFi transaction time: 209 ms
0;0;3;0;9;read: 4-4-0 s=4,c=1,t=24,pt=2,l=2,sg=0:147
0;0;3;0;9;WiFi transaction time: 208 ms
0;0;3;0;9;read: 2-2-0 s=102,c=1,t=0,pt=7,l=5,sg=0:4.2500
0;0;3;0;9;WiFi transaction time: 221 ms
0;0;3;0;9;read: 2-2-0 s=103,c=1,t=0,pt=7,l=5,sg=0:27.4375
0;0;3;0;9;WiFi transaction time: 208 ms
0;0;3;0;9;read: 2-2-0 s=104,c=1,t=0,pt=7,l=5,sg=0:23.3750
0;0;3;0;9;WiFi transaction time: 210 ms
0;0;3;0;9;read: 2-2-0 s=3,c=1,t=1,pt=7,l=5,sg=0:99.9
0;0;3;0;9;WiFi transaction time: 208 ms

Seems like many packets coming to NRF24L01+ in this time interval (140-200 milliseconds) and this causes NRF buffer overflow and packet loss.

Seems like problem with loosing messages is gateway firmware related.

Then I connect two controllers (my own perl script and MYSController 0.1.2.282) to esp8266 gateway (#define MY_GATEWAY_MAX_CLIENTS 2), both controllers receiving exactly the same data from gateway, but messages lost even more.

1 on graphs = one controller connected
2 on graphs = two controllers connected.

I'm not familiar with esp8266 network programming, but could it be that firmware looses incoming packets from nrf24l01+ due to blocking call to wifi-related network functions? Seems like during sending data to wifi network firmware does not have time to pick up all incoming packets from nrf24l01+ chip.

@Yveaux thank you for your reply. It is not failing wifi connection, as the same problem exists then I using serial connection to esp8266 (via on-board usb-uart converter on nodemcu board).

Nothing interesting in the serial logs (with debug mode enabled), just random absence of sensor data. Seems like I should connect sensor node to collect debug logs from node side.

Also speed is changed - much faster CPU (80 MHz vs 8 MHz) and much faster connection (wifi vs uart 9600 bps). Maybe this affects.

@hek graphs are drawn by Zabbix. My own Perl script connects directly to gateway, reads sensor data and sends this data directly to Zabbix.

Also, I have tried to write raw data from gateway directly to file and execute "tail -f logfile.txt | grep sensor-specific-id". With old pro mini gateway data from sensor comes every 10 seconds. From esp8266 gateway sensor data comes very irregular.

Also, every send() call in all my nodes followed by wait(25) call to reduce possible power issues and interference issues.

UPDATE: I have recompiled esp8266-gateway sketch with debugging enabled, but I get the same results with loosing messages then I connecting directly to uart port of esp8266 uart-usb converter.

Yesterday I switched gateway hardware from serial gateway based on arduino pro mini 3.3V and nrf24l01+ (connected directly to uart port of my mikrotik router) to esp8266 nodemcu and nrf24l01+ (exactly as at this page: http://www.mysensors.org/build/esp8266_gateway, using GatewayESP8266 sketch from 1.6 branch, revision https://github.com/mysensors/Arduino/tree/1035f84a431a8f591d31100c3e73e99a8245e345).

I have 4 nodes with ~27 sensors total, half of sensors sending data every 10 seconds, another sensors send data only if environment changed.

After switching to esp8266 my gateway started loosing packets (messages) from my sensor nodes:

Left side of graphs is esp8266, right side is old pro mini serial gateway, sensors sending data every 10 seconds. Distance between gateways is about 5-10 centimeters. Both nrf24l01+ boards oriented in the same direction.

nrf24l01+ board isn't changed at all (I'm using old board from pro mini serial gateway).

Also, I have tried different nrf24l01+ boards (different PCBs and different chip revisions, but seems like all of them are fake china chips). I have tried soldering 220 uF electrolytic and 0.1 uF ceramic capacitors directly to nrf24l01+ power pins. But nothing changed. Esp8266 gateway is losing messages.

Switching back to pro mini serial gateway is completely solves issue (as shown in graph above).

What else can I try to fix this? Could it be interference between wifi chip and nrf24? Or, maybe, this is software problem? Maybe non-interrupt driven polling of nrf24l01 causes loosing messages coming too often?

@Bens did you resolved your issue with poll call?

@ahhk https://www.bosch-sensortec.com/de/homepage/products_3/environmental_sensors_1/bme280/bme280_1

Average current consumption (1Hz data refresh rate)
1.8 μA @ 1 Hz (H, T)
2.8 μA @ 1 Hz (P, T)
3.6 μA @ 1 Hz (H, P, T)
H - humidity, P - pressure, T - temperature

0.1 μA in sleep mode

Supply voltage 1.71 - 3.6 V

I'm using BME280 (from aliexpress), very good and accurate sensor. But sensor price is not comfortable for me.

Easy to use (I'm using adafruit bme280 libraries with MySensors).

Dallas sensor reading code contains CRC checksum validation, so invalid readings from sensor should be skipped.

Is it possible to use NRF24LE1 (L01+MCU) as simple NRF24L01+? Are there any of these LE1 modules fake too?

Question inspired by this topic: http://forum.mysensors.org/topic/1774/introducing-mysensors-on-nrf24le1

You should not query sensor temperatures every 750 ms. Try this code with proper pause between sensor readings: http://forum.mysensors.org/topic/1562/door-motion-and-temperature-sensor/34

Also, your code is in constant 750ms delay, so incoming messages are delayed or even skipped. You should use newer code from git with non-blocking sensor readings: https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/DallasTemperatureSensor/DallasTemperatureSensor.ino

Your code looks like this now:

void loop()
{
    gw.process(); 
    delay(750); // 750ms of no incoming messages processing, no response to relay msgs
}

You can request values directly from another sensors for your LCD sensor node, but it's better to send LCD text data directly from controller to LCD node. Requesting data directly from another nodes is not very good choice, because of this nodes must not use deep sleep (so must not be battery powered).

My LCD node contains two 2004 LCD displays and receives text data for every display line from controller. But I'm using my own perl script as controller.

@CaptainZap You should not query dallas sensor temperature every 750 ms. This heats up sensor itself and quite useless.

Use something like this:

unsigned long SLEEP_TIME = 30000; // Sleep time between reports (in milliseconds)
unsigned long lastRefreshTime = 0;

void loop()
{
	gw.wait(100);
  
	boolean bNeedRefresh = (millis() - lastRefreshTime) > SLEEP_TIME;
	if (bNeedRefresh)
	{
		lastRefreshTime = millis();

		DallasSensors.requestTemperatures();
		gw.wait(750);
		float tempC = DallasSensors.getTempCByIndex(1);
		float difference = lastTemperature - tempC;
		if (tempC != -127.00 && abs(difference) > 0.5)
		{
			// Send in the new temperature
			gw.send(tempMsg.set(tempC, 1));
			lastTemperature = tempC;
		}
	}
}

@epierre in general, you are right, but there are exceptions.

This measurements, but one sensor per graph:

And 6-day graph of all sensors:

@gigaguy
example response of sensors for natural gas (left) and alcohol (right):

@gigaguy pin 13 connected to board's led
Warm up is just 3-minute pause (with led blinking) between power up and start of main loop measurements transmission. Cold sensors shows very big measurements, so I heating them up for 3 minutes.

I'm using similar sensors, this test sketch works fine for me, but I'm using raw readings from this sensors.
8 sensors connected to A0-A7 pins on arduino nano directly to analog output pin on each sensor board.

#include <SPI.h>
#include <MySensor.h>  

unsigned long SLEEP_TIME = 10000; // Sleep time between reports (in milliseconds)

#define NODE_ID										4

MySensor gw;
MyMessage msg(0, V_VAR1);

int lastLightLevel[8] = {0};
unsigned long lastRefreshTime = 0;

void setup()
{
	pinMode(13, OUTPUT);
	// warm up sensors (3 minutes)
	for (int i = 0; i < 180; i++)
	{
		digitalWrite(13, HIGH);
		delay(250);
		digitalWrite(13, LOW);
		delay(250);
		digitalWrite(13, HIGH);
		delay(250);
		digitalWrite(13, LOW);
		delay(250);
	}
	gw.begin(NULL, NODE_ID);

	gw.sendSketchInfo("GasSensors", "1.5");

	gw.present(1, S_AIR_QUALITY, false, "MQ-2");
	gw.present(2, S_AIR_QUALITY, false, "MQ-3");
	gw.present(3, S_AIR_QUALITY, false, "MQ-4");
	gw.present(4, S_AIR_QUALITY, false, "MQ-6");
	gw.present(5, S_AIR_QUALITY, false, "MQ-7");
	gw.present(6, S_AIR_QUALITY, false, "MQ-8");
	gw.present(7, S_AIR_QUALITY, false, "MQ-9");
	gw.present(8, S_AIR_QUALITY, false, "MQ-135");
}

void loop()
{
	gw.wait(100);
  
	boolean bNeedRefresh = (millis() - lastRefreshTime) > SLEEP_TIME;
	if (bNeedRefresh)
	{
		lastRefreshTime = millis();
	}
	for (int i = 0; i < 8; i++)
	{
		int lightLevel = 0;
		for (int j = 0; j < 32; j++)
			lightLevel += analogRead(i);
		lightLevel = (lightLevel / 32);

		int nDifference = lastLightLevel[i] - lightLevel;
		if ((abs(nDifference) > 5) || bNeedRefresh)
		{
			gw.send(msg.setSensor(i + 1).set(lightLevel));
			lastLightLevel[i] = lightLevel;
		}
	}
}

Raw ADC readings are 20-80 (differs from sensor to sensor) for fresh outdoor air.

@hek It seems that I did it. If this push request is correct, what I should patch? Development branch, master branch or both?

@hek I have forked MySensors project, added 3 commits into master branch with updated libraries and updated dallas sensors example (lower power usage).

I'm using similar code in my own version of MySensors 1.5-dev in my home, but I havn't tested this committed 1.4.1 github code on real hardware, so I will make PR after test on real hardware.

https://github.com/mysensors/Arduino/compare/master...roboprint:master?diff=split&name=master

@hek thank you, I'll read and try on dallas&onewire

@hek as I said before, Dallas library is bit outdated. Is it possible to update dallas and onewire libraries? I provided links for newer versions of this libraries in this thread. I can do PR in github myself, but I don't know how to do it I need to read github manuals first

requestTemperatures() is can be non-blocking in newer version of dallas library, so code can deep sleep (better for batteries) or process messages (better for repeaters and msg-receiving nodes) about 750 ms.

@CaptainZap also try to backup and clean C:\Users***\Documents\Arduino\ directory

@CaptainZap https://github.com/mysensors/Arduino/archive/master.zip

@CaptainZap

http://www.mysensors.org/download/ click on Download button under "1.4 - Latest Release" section, download zip archive, extract archive and check Arduino-master\libraries\MySensors\Version.h file.

@CaptainZap yes, but update two libraries (OneWire and Dallas).

gw.wait() function was added 1 feb 2015: https://github.com/mysensors/Arduino/commit/d45a48d8b786656968fb4b45b049e16700dd3fd0 so you should use latest stable 1.4.* code.

DallasSensors.requestTemperatures(); delays code execution up to 750ms. MySensors DS18B20 library is bit outdated, you should update library (https://github.com/milesburton/Arduino-Temperature-Control-Library) and use following code:

In setup:

	DallasSensors.begin();
	DallasSensors.setWaitForConversion(false);

In loop:

		DallasSensors.requestTemperatures(); // no delay here
		gw.wait(750); // insert another value for non-12-bit resolution
		float tempC = DallasSensors.getTempCByIndex(1);

@hek thank you!

I want to note what you changed order of ack and description arguments here: https://github.com/mysensors/Arduino/commit/b482a8eb7a09fe46f8b58d38fb5944f5d651892a
Site documentation uses old argument order.

Looks like MySensors library API docs is missing this useful wait function.

@tekka I have googled for [avrdude bootloader "bytes of flash written"] and found many answers about big upload size for bootloader (> 32000 bytes). It seems that big size is the way it should be.

I have solved problem. I must power up node with newly burned bootloader but without sensor node firmware and upload firmware using MYSController

Incorrect way is: burn bootloader, burn sensor node firmware, powerup sensor.

Thank you for great software!

@tekka I have noticed this, but I thought that this is due to the peculiarities of bootloader upload process (upper end of memory).

 Directory of C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\MySensors

14.06.2015  00:08    <DIR>          .
14.06.2015  00:08    <DIR>          ..
14.06.2015  09:59             5 548 MYSBootloader.hex
               1 File(s)          5 548 bytes

For sketch size is too big (32722 bytes), real sketch size is 19928 bytes.

In any case, thanks for the help, I'll try to figure it out or try to download it manually using avrdude.

Hello, how to verify right bootloader is uploaded to arduino?

I'm using two Arduino Pro Mini 328 5.0V 16Mhz, one as ArduinoISP programmer and one as sensor node to upload bootloader and firmware.

I followed manual (http://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/76) step by step.

I have tried MYSBootloader.hex coming from latest MYSController 0.1.2.280 and MYSBootloader.hex (1.1) from github with same results.

Upload log is here:

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v1 -PCOM10 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x06:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xF7:m 

avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM10
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0x06"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x06:
avrdude: load data efuse data from input file 0x06:
avrdude: input file 0x06 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xDA"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDA:
avrdude: load data hfuse data from input file 0xDA:
avrdude: input file 0xDA contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xF7"
avrdude: writing lfuse (1 bytes):

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v1 -PCOM10 -b19200 -Uflash:w:C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/MySensors/MYSBootloader.hex:i -Ulock:w:0x0F:m 

avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xF7:
avrdude: load data lfuse data from input file 0xF7:
avrdude: input file 0xF7 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude done.  Thank you.

Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM10
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/MySensors/MYSBootloader.hex"
avrdude: writing flash (32722 bytes):

Writing | ################################################## | 100% -0.00s

avrdude: 32722 bytes of flash written
avrdude: verifying flash memory against C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/MySensors/MYSBootloader.hex:
avrdude: load data flash data from input file C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/MySensors/MYSBootloader.hex:
avrdude: input file C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/MySensors/MYSBootloader.hex contains 32722 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 32722 bytes of flash verified
avrdude: reading input file "0x0F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0F:
avrdude: load data lock data from input file 0x0F:
avrdude: input file 0x0F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude done.  Thank you.

Fuses looks like right:

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as F7
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 6

MYSController log after node with new bootloader start:

14.06.2015 10:14:46	STARTUP	Initialize message logging
14.06.2015 10:14:46	STARTUP	MYSController 0.1.2.280
14.06.2015 10:14:46	STARTUP	FPC 2.6.4 / Lazarus 1.4
14.06.2015 10:14:46	STARTUP	still under development :) tekka 2015
14.06.2015 10:14:46	STARTUP	Load INI file...
14.06.2015 10:14:46	STARTUP	INI version 0.1.2.280
14.06.2015 10:14:46	INFO	*** Logging START ***
14.06.2015 10:14:46	VERSION	MYSController 0.1.2.280
14.06.2015 10:14:46	STARTUP	INI file loaded
14.06.2015 10:14:46	STARTUP	Loading FW repository...
14.06.2015 10:14:46	REPO	FW "Blink" loaded. t=10, v=1, blocks=72, crc=0xD098
14.06.2015 10:14:46	REPO	FW "TimeReporter" loaded. t=20, v=1, blocks=840, crc=0x4AC5
14.06.2015 10:14:46	REPO	FW repository loaded. Items=2
14.06.2015 10:14:46	STARTUP	Initialize message types
14.06.2015 10:14:46	NODE	New node discovered, node id=0
14.06.2015 10:14:46	NODE	New node discovered, node id=255
14.06.2015 10:14:49	INFO	Connected to 192.168.0.1:12345
14.06.2015 10:14:59	UPDATE	4295098648
14.06.2015 10:21:26	CHILD	New child discovered, node id=0, child id=0
14.06.2015 10:21:26	RX	0;0;3;0;9;read: 255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
14.06.2015 10:21:26	RX	0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,sg=0,st=bc:0
14.06.2015 10:21:28	RX	0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
14.06.2015 10:21:28	RX	0;0;3;0;9;send: 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
14.06.2015 10:21:30	RX	0;0;3;0;9;read: 3-3-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
14.06.2015 10:21:30	NODE	New node discovered, node id=3
14.06.2015 10:21:30	CHILD	New child discovered, node id=3, child id=internal
14.06.2015 10:21:30	TX	3;255;3;0;6;M
14.06.2015 10:21:30	RX	3;255;3;0;6;0
14.06.2015 10:21:30	RX	0;0;3;0;9;send: 0-0-3-3 s=255,c=3,t=6,pt=0,l=1,sg=0,st=ok:M
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=255,c=3,t=11,pt=0,l=7,sg=0:Balcony
14.06.2015 10:21:32	RX	3;255;3;0;11;Balcony
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0
14.06.2015 10:21:32	RX	3;255;3;0;12;1.0
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=1,c=0,t=16,pt=0,l=20,sg=0:Photoconductive Cel
14.06.2015 10:21:32	CHILD	New child discovered, node id=3, child id=1
14.06.2015 10:21:32	DEBUG	Update child id=1, type=LIGHT_LEVEL
14.06.2015 10:21:32	RX	3;1;0;0;16;Photoconductive Cell
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=2,c=0,t=6,pt=0,l=3,sg=0:ds0
14.06.2015 10:21:32	CHILD	New child discovered, node id=3, child id=2
14.06.2015 10:21:32	DEBUG	Update child id=2, type=TEMP
14.06.2015 10:21:32	RX	3;2;0;0;6;ds0
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=3,c=0,t=6,pt=0,l=3,sg=0:ds1
14.06.2015 10:21:32	CHILD	New child discovered, node id=3, child id=3
14.06.2015 10:21:32	DEBUG	Update child id=3, type=TEMP
14.06.2015 10:21:32	RX	3;3;0;0;6;ds1
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=4,c=0,t=6,pt=0,l=3,sg=0:ds2
14.06.2015 10:21:32	CHILD	New child discovered, node id=3, child id=4
14.06.2015 10:21:32	DEBUG	Update child id=4, type=TEMP
14.06.2015 10:21:32	RX	3;4;0;0;6;ds2
14.06.2015 10:21:32	RX	0;0;3;0;9;read: 3-3-0 s=5,c=0,t=6,pt=0,l=3,sg=0:ds3
14.06.2015 10:21:32	CHILD	New child discovered, node id=3, child id=5
14.06.2015 10:21:32	DEBUG	Update child id=5, type=TEMP
14.06.2015 10:21:32	RX	3;5;0;0;6;ds3
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=6,c=0,t=6,pt=0,l=3,sg=0:ds4
14.06.2015 10:21:33	CHILD	New child discovered, node id=3, child id=6
14.06.2015 10:21:33	DEBUG	Update child id=6, type=TEMP
14.06.2015 10:21:33	RX	3;6;0;0;6;ds4
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=7,c=0,t=6,pt=0,l=3,sg=0:ds5
14.06.2015 10:21:33	CHILD	New child discovered, node id=3, child id=7
14.06.2015 10:21:33	DEBUG	Update child id=7, type=TEMP
14.06.2015 10:21:33	RX	3;7;0;0;6;ds5
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=8,c=0,t=6,pt=0,l=3,sg=0:ds6
14.06.2015 10:21:33	CHILD	New child discovered, node id=3, child id=8
14.06.2015 10:21:33	DEBUG	Update child id=8, type=TEMP
14.06.2015 10:21:33	RX	3;8;0;0;6;ds6
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=9,c=0,t=6,pt=0,l=3,sg=0:ds7
14.06.2015 10:21:33	CHILD	New child discovered, node id=3, child id=9
14.06.2015 10:21:33	DEBUG	Update child id=9, type=TEMP
14.06.2015 10:21:33	RX	3;9;0;0;6;ds7
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=10,c=0,t=6,pt=0,l=3,sg=0:ds8
14.06.2015 10:21:33	CHILD	New child discovered, node id=3, child id=10
14.06.2015 10:21:33	DEBUG	Update child id=10, type=TEMP
14.06.2015 10:21:33	RX	3;10;0;0;6;ds8
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=11,c=0,t=6,pt=0,l=3,sg=0:ds9
14.06.2015 10:21:33	CHILD	New child discovered, node id=3, child id=11
14.06.2015 10:21:33	DEBUG	Update child id=11, type=TEMP
14.06.2015 10:21:33	RX	3;11;0;0;6;ds9
14.06.2015 10:21:33	RX	0;0;3;0;9;read: 3-3-0 s=1,c=1,t=23,pt=2,l=2,sg=0:49
14.06.2015 10:21:33	RX	3;1;1;0;23;49
14.06.2015 10:21:36	RX	0;0;3;0;9;read: 3-3-0 s=3,c=1,t=0,pt=7,l=5,sg=0:26.5625
14.06.2015 10:21:36	RX	3;3;1;0;0;26.5625
14.06.2015 10:21:37	RX	0;0;3;0;9;read: 3-3-0 s=1,c=1,t=23,pt=2,l=2,sg=0:49
14.06.2015 10:21:37	RX	3;1;1;0;23;49

Node successfully start and connecting to gateway with new bootloader, but then I issue reboot command in MYSController, node hangs up completely, even reset button isn't working. Only power off, then power on helps. Assign firmware isn't working also (nothing happens).