Perhaps the 3.3V voltage regulator on the Nano does not provide enough current to power both the radio module and the OLED display? You could test the setup first with the display disconnected. If that works then you can try and find a way to power the display from a different source.
@thaliquids I would tackle this by finding a controller (here's a few examples of controllers: https://www.mysensors.org/controller) that supports Philips Hue. The controller would then get an event each time a button is pressed on the tap. Then you link a script or other action to that event which switches the tube light on or off.
The advantage of using a controller is that the corresponding action can be done on a device totally different from Hue (MySensors, Sonoff, Z-Wave etc.)
@mateos78 The Domoticz ui gets refreshed every 10 seconds or so. I too see that updates to sensors or switches can be a bit lagging. The logs update pretty much realtime, so you can use that to confirm that Domoticz picks up the differences instantly.
Great project you got started! One thing to consider is that the Nano is not the most suitable Arduino for battery powering... Reason is that it has a USB TTL chip on it that consumes power when idle which does not add to your sensor (except for the times you want to change its sketch). Perhaps it would be best to redesign it to a Pro Mini 3.3V 8MHz. The battery power tips on the build section has more info on that.
@mateos78
What are the symptoms you're experiencing? When changing the dim value using the encoder. Does Domoticz pick up that change? When changing the dim value on the Domoticz end. Does the node change as well?
I have two of these dimmer nodes with rotary encoders based on the examples and working with Domoticz. What I did find out when building them is that the radio communication needs to be working well otherwise the dimmer seems (sometimes) unresponsive to the rotary encoder. After fixing radio communication (proper module and capacitors for powering it) these sketches worked like a charm. When using message signing the importance of good communication with the gateway becomes even more important as the messages become larger.
I would expect there to be two options: Either the Sonoff connects to the Ewelink cloud service and polls if there are actions to be taken. So the actions are not sent directly to the Sonoff unit, but the Sonoff reads at some point something needs to be done.
Another approach would be that a tunnel of some kind is initiated by the Sonoff. The Ewelink service then sends commands back through this tunnel.
@kalina said in What did you build today (Pictures) ?:
I have assembled a few UPS ... now I am testing these hardware.
Looks neat! How did you do the cutout of the sides of these enclosures?
@esumo The P1 interface of the Dutch smart meters would show four counters (peak/low consumption and peak/low production) in a telegram which Domoticz uses to update the counters accordingly. The virtual sensors will not produce these graphs I think. The best you could try is to emulate the P1 behaviour by sending the telegrams that the P1 interface produces on a serial interface and then connect it as if it were a P1 interface. This would be beyond MySensors scope and more a Arduino/ESP8266 serial protocol exercise (although it would not stop you to also send out the values gathered using MySensors).
@d-dow: Do I understand correctly that you already have an Arduino with DHT11 connected and working and you would like to connect it to a Domoticz controller so you can use the temperature and humidity values in Domoticz? And do I understand correctly that you are wondering if it is possible that instead of sending these temperature and humidity values to the controller over a radio connection (NRF24 or ESP) use the USB connection?
That will not be possible I think using MySensors. What you could do (instead of MySensors) is to let these values be written to the serial output of the Arduino (Serial.print/Serial.println). Then create a Bash script on the Domoticz controller host (assuming it runs Linux) which periodically reads the serial port and parses these values to a Domoticz virtual sensor using the Domoticz API. I do the same for a DHT22 sensor connected to my Linux NAS, so you don't even necessarily have to connect that Arduino to the Domoticz controller.
Not sure what would be the best way, but two options spring to mind:
The second option has the advantage that the controller always knows the correct state of the light and it makes it easier to control the light from timers or different events (light sensors, motion, etc) and the buttons at the same time.
The basis for the three nodes could be this example: https://www.mysensors.org/build/dimmer, where you choose the example with the rotary encoder for the dimmer nodes (and leave out the LED strip).
@lis610 said in 
Insulated Whole House Fan:
I am using RCWL-0516 Microwave Radar Sensor for on/off the display. This sensor is very sensitive. I just want to activate the display in a close range. Any suggestions?
You could try the XYC-WB-DC radar sensor. This one allows the sensitivity to be adjusted by changing a resitor value. Here's a Youtube video about it:
Modifying a XYC-WB-DC Microwave Motion Sensor for use in a Sonoff SC – 19:09
— Blair Thompson
I'm waiting for mine to come in from China, so no first hand experience yet on how these sensors work.
@pdp8 By default Domoticz will add a S_BINARY, S_DOOR, S_MOTION and S_DIMMER (and likely a few others) device in the form of a switchable lamp. You can add it to the active devices and then change the type to be a different device.
For example when you create a S_MOTION device, it initially gets added as a lamp in Domoticz, but then you can later change the switch type to be a motion sensor. This changes the icon displayed in Domoticz and also stops you from changing the state.
On my battery powered bicycle light I use petroleum jelly on the battery terminals. It makes changing batteries a little bit more messy than usual, but it seems to do the trick for over two years now.
@Tekka You steered me in the right direction. Thanks again! I did a search on wdt_reset to get a better idea of what it does and then found posts describing that if something keeps the CPU occupied for a prolonged time that the watchdog can kick in thinking the MCU has stalled/froze. I also understood that the MySensor library will reset the watchdog timer regularly.
Looking at my sketch I found that I used delay() at certain points. The five minute sleep was done using wait(). Replacing delay() with wait() throughout the sketch fixed the issue for me! It has not reset overnight where otherwise I would see it reset every 25 seconds or so. Now I will look at the other examples that would reset itself.
I'm in good shape now to roll out MYSBootloader and upgrade my nodes to 2.2.0 at the same time.
@cdr @Henry I ran into the same issue. Turned out to be a syntax issue in the boards.txt file. If you change:
MYSBL.menu.frequency.MYSBL16.f_cpu=16000000L
into
MYSBL.menu.frequency.MYSBL16.build.f_cpu=16000000L
Then it works again. Adding build. needs to be done for the other menu entries as well.
@tekka Thanks for the quick response (and the work done on this bootloader). I’ll give that a try in the coming days and report back.
Last year I started experimenting with OTA upgrades using MYSBootloader (using the pre-built one from Github (pre3 version? Not sure). I built a small test environment with a handfull of nodes and managed to successfully change the sketch over the air.
Happy with the results I upgraded some existing "production" sensors to MySensors 2.1.1 and in the process swapped the bootloader of those nodes to MYSBootloader, so they would be OTA ready for the next round of upgrades. After successfully doing this to a handfull of nodes I repeated it on a different node and noticed in the logfile of Domoticz that the node was continuously presenting itself to the controller (about each 25 seconds or so). Otherwise the node seemed to work (updated temperature and humidity, but did not sleep for five minutes as it was supposed to). The previous nodes were Arduino Nano based and this one was Arduino Pro Mini based. So at first I thought it would be a Pro Mini issue (which would be peculiar as like the Nano it was also using an Atmega 328p @16MHz). But when I would try another Nano that one would also reset itself continuously(!). If I revert the bootloader back to the Nano or Pro Mini one and try the same sketch the resets are gone. It's driving me insane and I'm at a loss why I cannot produce MYSBootloader nodes anymore that don't reset themselves.
In the process of troubleshooting I found out that MYSBootloader needs to be compiled with the same channel settings as the gateway it connects to. My "production" environment uses a different (non-default) channel, so the nodes that do have MYSBootloader need to be redone (doh!). I have also managed to download the sources, set the correct channel and build it. Unfortunately these bootloaders also show the resets.
Other things I tried:
No differences unfortunately. Does this sound familiar to anyone? What am I overlooking? I really would like to get this working again as I love the OTA idea (and have some nodes hidden away without easy access).