General Discussion

I agree you have centered all the critical points: Ordering a pcb, all components and then soldering it is quite a barrier for "ordinary" people. Absolutely true! In fact my plan is to start a second Kickstarter campaign to sell some pre-assembled boards, if there are enough people interested and the feedback form the first campaign (not assembled pcb) is good. I have opened the d-diot website Friday, so the entire project is still a baby and I don't have a clear view of the next steps :grin: . In any case a final goal could be also a full finished product (case + board + Raspberry). For the ordinary user this will mean "plug in, take out your smartphone and play" What keeps you from having it open source and still sell assembled boards? In this moment only one "irrational fear" (please note the "" :wink: ).... loosing the possibility to keep the project sustainable and self-sufficient from an economical point of view (chinese clone, in other words). But I agree opening the hardware will improve and speed up the development and, at the end, the quality of the final product. The open source model works and this is a a fact (see Linux and Arduino). I think that a viable solution for me in this moment is to open at least the schematics; I'm evaluating this possibility from two days. 90% would buy a pre-made board from you. Yes I believe that too. Unfortunately the final price of a fully assembled board will be not so low, probably around 40-50€ (estimated), because today the assembly is not so cheap as the pcb manufacturing and the value of the components + radio modules is around 25€ (see here). So I prefer to keep also the DIY way open. Of course the price of a fully assembled board will drop with a massive production. Sorry for the long post but I think that there are great possibilities around the open source home automation, which is a good thing also for privacy and security, especially now in the cloud era, but, in my opinion, the problem is that the various projects (and there are many!) are fragmented and not integrated in a simple and plug&play solution for the normal user. In fact d-diot is born from this consideration. I have not talked about the other ideas / consideration to improve the experience of the others makers and that can generate some incomes to support the development, but for this post, I have already wasted enough bits with my bla bla bla, so I will proceed, if some other people are interested.

@zboblamont Thank you! - I didn't know if it was possible to send as a float or not. Now it is working as expected - :)

@mouskichab What controller package do you use? Does your controller have a scheduling option?

You don’t need MySensors for this, PubSubClient will do what you need.

Hello @hohm I added the code block to your message. Is the "Pumpe()" function your attempt for the second cycle, or do you want to add a second cycle to the Pumpe() function ? Because from what I see it's doing what you ask ? If humidity percentage is below limit activate pump, when pumped volume is over specified volume stop the pump, and after "fiveMinutes" are passed, reset the counter.

My mini board. [image: 1556711451754-photo_2019-05-01_14-50-00-resized.jpg]

@terence-faul said in Battery reporting: is it possible to implement battery reporting as in Battery status report is probably doable though work is ongoing in GNOME to have this systemwide and integrated into the proper config panels. Likewise with notifications, I'd rather have gnome send this in a generic manner for all battery-powered devices.

The error says "Invalid Home". Please check the home page setting a little higher up on the settings page.

@terence-faul any solution so far? I found this: create a file, e.g. mysensors_bootloader_130_8Mhz.json and save it to ~/.platformio/boards/ { "build": { "core": "arduino", "extra_flags": "-DARDUINO_ARCH_AVR -DARDUINO_AVR_PRO", "f_cpu": "8000000L", "mcu": "atmega328p", "variant": "standard" }, "frameworks": [ "arduino" ], "fuses": { "efuse": "0xFE", "hfuse": "0xD2", "lfuse": "0xE2", "lock": "0x0F", "unlock": "0x3F" }, "name": "MySensorsBootloader 1.3.0 (Atmega328P@8M,3.3V)", "upload": { "maximum_ram_size": 2048, "maximum_size": 30720, "protocol": "arduino", "require_upload_port": true, "speed": 57600 }, "url": "http://www.mysensors.org", "vendor": "MySensors" } the platformio.ini should look like this: [env:mysensors_bootloader_130_8Mhz] platform = atmelavr framework = arduino board = MYSBootloader_8MHz.hex src_build_flags = -I/Users/dirk/Arduino/libraries/MySensors lib_deps = # Using a library name but I do not know where to store the MYSBootloader_8MHz.hex

@bladeback sorry, but it is not possible at the moment, as mySensors only supports one radio at a time.

@rejoe2 Hi, Thanks for feedback, I'll try code from alowhum first.

@alowhum done

@skywatch Take a look at my pan tilt project. A stepper i.s.o. servo can easily be achieved. I would recommend to use the AccelStepper lib to have a smooth movement.

It doesn't seem to work properly. It seems data is.. garbled? The first node does show up in Domoticz. It got ID #2 (not 1). It has one child, which is of the correct type. But the other 5 don't show up. The second node I tried shows up in Domoticz.. but it's very weird. It gets ID 148, and things like the node name are not there. Similarly, the child also has weird data: ID: 45 Type: Unknown! Name: 4101763563 I'm going to try a shielded radio module. // Update: same issue. It seems, in the log below, that some of the messages don't come across completely? 0;255;3;0;9;1679510 TSF:MSG:FPAR REQ,ID=1 0;255;3;0;9;1679514 TSF:CKU:OK,FCTRL 0;255;3;0;9;1679517 TSF:MSG:GWL OK 0;255;3;0;9;1681281 !TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 sg=0,ft=0,st=OK:0 <- HERE 0;255;3;0;9;1696642 TSF:MSG:READ,2-2-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1 0;255;3;0;9;1696648 TSF:MS0;255;3;0;9;1698251 !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1 0;255;3;0;9;1702721 TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0: 0;255;3;0;9;1702727 TSF:MSG:BC 0;255;3;0;9;1702730 TSF:MSG:FPAR REQ,ID=2 0;255;3;0;9;1702734 TSF:PNG:SEND,TO=0 0;255;3;0;9;1702737 TSF:CKU:OK 0;255;3;0;9;1702740 TSF:MSG:GWL OK 0;255;3;0;9;1705198 !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 0;255;3;0;9;1716798 TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,G:BC 0;255;3;0;9;1716807 TSF:MSG11 TSF:PNG:SEND,TO=0 0;255;3;0;91716817 TSF:MSG:GWL OK ,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0 <- HERE 0;255;3;0;9;1724956 <- HERE TSF:MSG:READ,2-2-0,s=255,c=3,t=24,pt=1,l=1,sG:PINGED,ID=2,HP=1 D,0-0-2-2,s=255,c=3,t=25,pt=1,l=0;255;3;0;9;1728997 TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,G:BC 0;255;3;0;9;1729006 TSF:MSG10 TSF:PNG:SEND,TO=0 0;255;3;0;91729016 TSF:MSG:GWL OK

There are also some waterproof ultrasound distance sensors you could use

@alowhum Thank you for sharing this! - This looks like exactly the kind of thing I was trying to achieve. Hopefully I get some time at the weekend to test it out. Cheers! :)

@terence-faul this is not a fail prove design. Nodes are not typically moved even within one GW. Each GW must have each one channel and the same goes for nodes. Otherwise, in theory you may have a situation that the same node is reporting to one GW and then to the other GW. For controller this is going to be a chaos. A lot of data will be shared between two similar child IDs, i.e. for example two similar temperature child IDs for one node will have one measurement assigned through the first GW to the first temperature child ID and another measurement assigned to another child ID through another GW.