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).
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.
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.
Simple RS485 gateway and node for two BME280 sensors:
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.
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
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
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.
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)
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.
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?
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
@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
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?
@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!
@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?
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");
@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.
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.
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
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.
