General Discussion

One little project and you're hooked! You know you're going to want another sensor in the yard, so consider a gateway running MQTT (called a broker). Once you have that, it's really easy to add more sensors. But if you're really strong willed an will only be using two devices ever, you might look at https://nrf24.github.io/RF24/index.html. You can get an Arduino Nano and an nRF24 radio for about $3.50 from Aliexpress (downside: delivery takes ~2 months, so get 10 each.) MySensors Library can do this, too, but I find it a little bloated. Personal note: I'm 70, retired engineer, and have only four projects going right now.

@mfalkvidd Cheers! This project will keep me occupied for my 2 week hotel isolation stay.

They are programmed with the platform that you are using, assuming it support them.

I'm quite lazy, and use this approach and use a USB powerbank, and check if DHCP server is alive or dead (Dead= no 230V) https://raspi-ups.appspot.com/en/index.jsp

struggling with similar issue.... nodemcu 1.0 (esp8266EX) - connected on com6, but back of board says connect at 9600. serial monitor at 9600 can display correct messages at boot.. no AT command response, but then when i upload some simple code i get the following: .... Features: WiFi Crystal is 26MHz MAC: ec:fa:bc:27:cc:12 Uploading stub... Running stub... Stub running... Configuring flash size... Traceback (most recent call last): File "C:\Users\jph1l\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.1/tools/upload.py", line 66, in <module> esptool.main(cmdline) File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 3599, in main detect_flash_size(esp, args) File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 2848, in detect_flash_size flash_id = esp.flash_id() File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 688, in flash_id return self.run_spiflash_command(SPIFLASH_RDID, b"", 24) File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 948, in run_spiflash_command old_spi_usr = self.read_reg(SPI_USR_REG) File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 562, in read_reg val, data = self.command(self.ESP_READ_REG, struct.pack('<I', addr)) File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 386, in command p = self.read() File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 331, in read return next(self._slip_reader) File "C:/Users/jph1l/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.1/tools/esptool\esptool.py", line 2636, in slip_reader raise FatalError("Timed out waiting for packet %s" % waiting_for) esptool.FatalError: Timed out waiting for packet header esptool.FatalError: Timed out waiting for packet header any ideas - change usb cable, ports, confirmed the com not used elsewhere... any ideas? FYI - the blue LED on the NodeMCU does flash once you start the upload.. flash a couple of times then stops. Pressing the FLASH and holding down before the upload command or once it tries to connect etc there is no difference.

@NeverDie said in Looks as though ESP-NOW is finally working...: Anyhow, sleep current for ESP8266 and ESP32, the last time I checked anyway, was still kinda high, but I do wonder what the startup time would be if an ESP module were kept in a totally turned-off state until it was needed. Perhaps the higher transmit speed that is possible with a wifi PHY would allow high power to be used only briefly (~250ms in the example in the video), and so maybe total power consumed from the start of wake-up through the transmission may yet turn out to be a win? Power consumption in deep sleep is really low if using a barebone ESP32-WROOM or WROVER. I did a project in 2020 before the lockdown using a custom ESP32-WROOM in a Soil Moisture capactive sensor and took some measurements to check the power consumptions in each state. The results were: Power Consumption With delay (idle): 39,29 mA in the 3V3 input from FTDI adapter. In deep sleep: 5,4 uA in the 3V3 input from FTDI adapter. While transmiting (ESP-NOW protocol) the power spike was huge, an average of 200mA, and I think the peak demand was even higher (400 mA?) With 600mAh LiFePo4 Batteries, the expected duration is aprox. 5 months. No Regulator needed when using LiFePo4. If using regular LiPo or Li-Ion batteries, careful selection of the regulator is crucial because of the spike while transmiting if the regulator is not capable enough or close to the 3V3 pin of the module, a Brownout is quite probable. This duration (5 months) is calculated assuming that the processor wakes every 15 min to take a sample of the soil for 2 seconds. If the difference between the measured content and last reported value is less than 5% (aprox. Error of the probe), the value is not sent to the controller (no wifi used). It is estimated that 4 measurements per day are sent. If there is no different in moisture content in a days cycle (every 96 wakeups) the sensor reports the measured value along with voltage. Voltage is sent in every moisture report. It is not considered important to send more frequent updates of voltages, LiFePo4 have a flat discharge curve. The most impacting measure in extending the battery life in this design was the On-Time of the sensor necessary to stabilize the output (feeding the capacitive soil moisture sensor). It is observed that reducing the On-Time has an impact in the measured output. In the sensor, whenever I woke the sensor from deep-sleep I activate a mosfet to drive the feed to the capacitive soil moisture sensor and wait for 2,4 seconds.. that is the part of the cycle that is more critical to battery life. The time to transmit the data was on average 80 miliseconds (from ESPNOW initialization to data sent). Here is a dump from the serial monitor to check this duration: 16:21:19.694 > rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) 16:21:19.694 > configsip: 0, SPIWP:0xee 16:21:19.694 > clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 16:21:19.694 > mode:DIO, clock div:2 16:21:19.694 > load:0x3fff0018,len:4 16:21:19.694 > load:0x3fff001c,len:1044 16:21:19.694 > load:0x40078000,len:8896 16:21:19.694 > load:0x40080400,len:5828 16:21:19.694 > entry 0x400806ac 16:21:19.694 > Boot count: 8 16:21:19.982 > Moisture level (pre): 722.62 16:21:20.853 > Moisture level %: 0.00 16:21:20.853 > Voltage level: 2389.50 16:21:20.853 > Voltage Battery: 3.34 16:21:20.853 > Startig Wifi Now... 16:21:20.853 > Wifi Setup complete. 16:21:20.934 > Send success There is a possibility to further reduce power consumption. Yo can manipulate pint status and read the ADC while maintaing the main cores in deep sleep by using the low power co-procesor. This coprocesor would check if the value has changed since the last transmission and wake the main processor if it is necessary. And in relation to ESPNOW and MySensors, I used a TTGO-Lora board with ESP32 and LORA transceiver as the MySensors and ESPNOW gateway. The gateway processed the value from the sensors received by the ESP-NOW "custom" protocol to MySensors... the controller (Openhab) was only aware of sensors atached to the ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> Openhab I did also a proof of concept with a Repeter-translator from ESP-NOW to Mysensors: ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> TTGO-Lora (receives MySensor Messages) --> Openhab The ESP-Now MySensors gateway sketch was not very elegant but worked. The next step would be using ESPNOW as a new MySensor Protocol... to do it myself I should spent quite some time learning how MySensor Code works.. I have tryed in the past but never have the change to work enough time to understand it fully. If this transport is supported, I see quite an advante of ESP32 vs NRF5284, both would use the 2,4 GHz band, but ESP32 transmission power is +20dbm (vs +8 dbm for the NRF5284 if I am not mistaken), also, a barebone ESP32-WROOM price is 2 € and is not hard to hand-solder... to that you have to add the components to design a custom board but overall quite competitive. Pre-production test: [image: 1624899685783-20200501_114856-resized.jpg] [image: 1624899705979-20200501_114912-resized.jpg] Custom board (first try.. a cable to fix some design errors . :upside_down_face: ) [image: 1624899814991-20200613_102550-resized.jpg] [image: 1624899848632-20200613_102608-resized.jpg]

This is possible yes. In fact I used this setup before, but in the end I stopped using it and separated the gateway from the P1 handling. I noticed very high rates of CRC failures, since the mysensors stuff takes time to handle also, and during this time characters from the P1 port got lost. I should say though that after I separated these, I did some improvements on the P1 decoding which may give better results when it is being used together with the gateway. I didn't send it to mysensors but directly to mqtt. Tasmota is also able to handle the P1 stream by the way, with a template. https://tasmota.github.io/docs/Smart-Meter-Interface/

Lots of info here: https://forum.mysensors.org/topic/8735/cnc-pcb-milling?_=1624294898545 It's as close as you'll find to a complete walkthru. Turnaround is faster than JLPCB (an hour vs days). Otherwise, I would agree. TL;DR: for rapid iteration, or you simply want something fast, DIY PCB's are hard to beat. As to topicality, it's a subject not covered well on most other forums. CNC Zone has some posts, but that's about it. All in all, the tools keep getting better, and it's easier now than before to find speciallized bits that make the work easier.

@ejlane said in Completely lost about multiple door switches/lights/sensors: I wouldn't even bother with an Arduino/microcontroller at all for this. Just some diodes on each circuit and maybe some transistors for powering the large LED strips, or could also use tiny relays. But I don't see where it has anything nearly complicated enough to have code running on a chip to run anything on it. @itjobhunter if this is not helpful and you need more specific details and/or a quick napkin sketch I can throw something together to show what I'm trying to say. I think you are right. I really was just lost on how/where to start on building my solution, and someone suggest Arduino. I googled it, since I had no idea what it was, and MySensors was one of the search results with the best information and most knowledgeable members. I'll take your advice and work on an electrical solution as opposed to something more complex. I appreciate EVERYONE'S comments, and steering me in the right direction!

@skypn your post ended up in the moderation queue (spam prevention), but I have released it now. Sorry for the inconvenience, and welcome to the forum!

I, too, am a "gray hair" (if I had hair). I despise cloud dependent devices. The reasons are many. ISPs, despite what they say, are not reliable. ISPs are so close to be monopolies, that they act like them. Your ISP can, and will, prevent access to the cloud if they have a competing product. The manufacturers of cloud dependent devices, sell your information and statistics on how you use the devices. This is how they make money. When one of these manufacturers goes out of business, the company that buys up the IP continues to sell that information and ceases the little support that one did get. I might be getting a little paranoid here, but I'm pretty sure there is unrelated-to-function software (spyware) incorporated into many products. (In the late 90's, the company for which I worked resisted the temptation to do so, despite heavy pressure from marketing.) I call it "ET phone home" Maybe the software is innocuous enough, but it can be hijacked by bad actors. There is another problem plaguing home automation and that is poorly designed and poorly documented (which leads to pathetically supported) hardware and software. More so the latter. FAQs and forums are afterthoughts of the slothful, but now it's all we have. I agree with ProfRob and I would add "better documentation". As a note, when I pull on my pants, I sit on my bed, start my pants onto my feet, roll back and pull both legs up at once ;)

@mfalkvidd Thanks a lot! I just made some tests and it looks promising. :grin: :grin: :grin:

Perhaps my definition about "controller", is a bit broad here. What could be done, is to have a thin "controller", that receives MQTT from the existing gateway, hands out IDs if they are requested from a new node, and translate the message into homie compliant topics. That is all it has to do, should not care about the rest of the automation at all. Should also be able to translate back from homie compliant to mysensors. This could be written in python, c#, javascript, rust etc. The benefit is that you have (relatively) easy editing of configurations at hands, without re-uploading sketches to your gateways / nodes, if you decide that node X should be named Y instead. And I am in no way trying to treat anyone as a fool!

@NeverDie I have two of them and made some applications using PlatformIO IDE. I like the Wio Terminal. The only issue that I experienced until now is that I couldn't get one of my apps, which is repeatedly posting sensor data to Azure Storage Tables, running without hangs for longer time periods. If you can live with the watchdog it is useable. I didn't try the bluetooth and sd-card functions. A good thing is that you can easily enable debugging with a little bit soldering and a J-link debugger.

@hek From what I've read, to better avoid browser fingerprinting, Brave apparently camouflages itself as Chrome: https://www.ctrl.blog/entry/brave-user-agent-detection.html That would make sense, since there would be less uniqueness if mixed into a larger pool, and Chrome has the largest pool by far. Perhaps that would mean you'd be getting tips from seemingly "out of the blue". Brave is pretty new, but there's a good chance the idea might catch on when people realize it works in their best interests.

Ah crikey, you're right there. Thanks @mfalkvidd, time to dust off the soldering iron. Cheers

@NeverDie said in Advisory: put IOT devices on a separate LAN/vLAN for better security: @monte https://www.ebay.com/itm/X10SLH-N6-ST031-Supermicro-E3-1200-v3-LGA1150-Motherboard-3x-X540-T2-6x-10GbE/184546263249?hash=item2af7d080d1:g:CCUAAOSwoP1gSWhO Lest I mislead anyone, I subsequently contacted to the seller and, despite the wording, it doesn't include an E3-1200 with the board. He just meant that as shorthand to refer to the processor family that's compatible with the board. That said, there are a ton of inexpensive used LGA1150 CPU's on ebay that could serve the purpose.