Using MySensors since version 1.5.0 and loving it!
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.
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.
@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.
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.
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.
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).
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).