Not sure if others would have interest in this, but I'm designing a PCB for an easy-to-solder TH node. As presently conceived, it would have 3 surface mount components (an LED on the front and a resistor and capacitor on the back), plus a DIP atmega328p, a header to accept an inexpensive si7021 TH breakout board, an FTDI header, and an RFM69HW. The idea is that it would run at 8Mhz and be powered by two AA batteries, so it's sized to be compact but still easy to solder. The same thing could be achieved with wires and some of the other boards out there, but this might be a little tidier if a TH mote is what you want as either the starting point or the end-point.

PCB dimensions are 0.65x2.55 inches. i.e. it is narrower than a typical AA battery holder, but roughly the same length.

The LED and resistor are optional, and you could forego the capacitor as well if you wanted a truly bare bones TH solution. However, the pads are there if you wanted to utilize them. Also, you could skip the si7021 BoB if you wanted just a generic mote.

I had hoped that someone would make an easy to solder board like this for the RFM69HW, but I got tired of waiting and finally decided to just make my own.

I found a good place to do range testing.... too bad I didn't bring the gear!

Good news! Last night I did some accelerated load testing on the supercap. First I charged it to 3.6v and then I hooked up an RFM69HW mote which woke up once a second to do 3 things: 1. check the voltage level, 2. turn on an LED for 1ms to simulate a sensor load, and 3. transmit a packet containing the voltage data using the RFM69HW.. Bottom line: 14,111 packets transmitted before running out of juice.

Not bad for a first attempt.

Yesterday received the PCB. Today assembled for testing this battery-powered nRF52-based passive infrared motion detector:

Made this 12 button keypad. Requires only one analog pin to read which button is pressed, and any button press can also wake an arduino from sleep:

Consumes no power when no button is pressed.

A pair of lithium AA primaries is hard to beat because:

1. Unlike alkaline's, they don't leak.
2. Have a look at the discharge curve: https://data.energizer.com/pdfs/l91.pdf By the time they drop to 2.4v, if not before, you'll want to replace them.
3. Obviously much longer life, both shelf life (20 years!) and energy capacity.

I think running 8Mhz from the internal RC is a no-brainer: wake up time is less than 4us. So, if your node wakes up often, you'll save a ton of energy over time.

The best time to take your battery measurement is immediately after a Tx. That will give you the most conservative reading. Save that measurement in a variable and then send it in your next transmission. Switch on your ADC just before Tx and take your first ADC measurement during Tx, because you have to throw out the first measurement anyway. That way you can take a fresh (and valid) ADC measurement just after Tx before the voltage rebounds.

Hope that helps!

Here's the version that I most recently assembled:

As you can see, the 15F supercap is now on the board itself. It works fine.

I've since made a few refinements and have sent the new files off to be fabbed. The newest version of the PCB will measure roughly 22mm x 22mm.

Put together this pro mini nRF24 shield for testing...

I have a number of sensor projects that sit within the nice footprint of a Pro Mini. Now I want to find a kind of universal power platform--hopefully small--to power them. So far, what I came up with was this, which runs the Pro Mini from 2xAAA batteries, and where the Pro Mini (and whatever the project built on it) simply "plugs in" to it:

Is there anything better? Ideas? Comments?

@feanor-anglin said in Where did everyone go?:

I just think such initiatives could meet with higher interest from everyone involved in the development of MySensors, because it would be mutually beneficial.

This is the first I've heard of your project, but I have no idea where it is. Maybe post a link to it? If you already have in some other thread, the problem is that not everyone reads every thread or tracks every post.

I'm surprised just how much variance in mains voltage there can be over a 24 hours period. Here's a graph of Ting's log data from yesterday:

There's a difference of 11 volts between the low and the high voltage measurements. Also, there was a considerable dip in voltage overall between 3:30pm and 6:30pm, as you can see from the graph.

I referenced Kevin's board merely as an example. I'm sure lots of alternatives exist if you were to go looking for them.

@idanronen This: https://www.kevindarrah.com/wiki/index.php?title=TrigBoardV7
Not sure ifhe's using esp-now lately, but it would be an obvious match for his trig boards. Early on he was doing typical wi-fi connections through a router, which is obviously slow if having just awoken.

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.

ESP-NOW is a peer-to-peer protocol that doesn't go through a wi-fi router, so it doesn't encounter the usual multi-second delay it might if it were waking up and reconnectig with a wi-fi access point first.

This guy gives a nice overview:
ESP-NOW | Getting Started With ESP8266 Including Demo Sketches – 10:34
— bitsNblobs Electronics

I would have preferred to see an implementation of wi-fi direct, which is similar in concept and which has had android support for about 10 years, but I'm not sure where to find modules that are easily wi-fi direct capable.

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?

So, the answers are:

1. No audible alarm in the unit itself. Instead, it contacts you via either the phone app, by email, by texting, or by telephone if it detects a fault.
2. If a fault is detected, it guides you into finding out where it is. If you're not able to locate the fault yourself, then Ting says it will pay up to $1000 for an electrician to find the fault, perhaps depending on what fault it thinks it detects.

At the sensor level, it monitors house voltage in real time, and keeps track of the high and the low for each day. It says that can be relevant if the transformer feeding your house from the utility is near a failure point, in which case it can alert you to contact the utility. It also monitors high frequency activity on the electrical system, which is what it uses to detect arcing.

Honestly, I'm not expecting it will ever actually detect a meaningful problem, but who knows? It was free from my insurance company, and so I presume they did a due-diligence analysis and concluded that the risk reduction justified their cost of buying and distributing it to their customers. If nothing else, the power monitoring might be useful in logging brownouts and over-voltages on the mains: if a server or other device goes wonky, I guess I could see whether it correlates to a voltage fluctuation on the mains. If there is a home assistant interface for it, then perhaps I could log all the real-time data using that and use grafana to graph it. That might be interesting data to review if a fault were ever detected.

https://www.tingfire.com/

Good questions. I'll update when I find out. It phones home via wifi, over my internet connection. And it has a phone app.
Maybe I'll get a lower rate from my insurance company for plugging it in? I need to double check. The same insurance company has an in-car bluetooth device which, if you agree to use it, spys on your driving habits, which is admittedly a bit 1984, but the upside is that if, from the data it gathers, it decides you are a "safe" driver, it qualifies you for reduced car insurance rates. Something like 30-50% lower rates are possible, which is significant. It's all voluntary...at least for now.

I got a free IOT "ting" from my insurance company. "Ting" is the official name. Made by Whisker Labs. I plug it into an electrical outlet and from that point forward it listens to the in-home power grid for any signature signs of electrical arcing, which can be a fire hazard. The idea is that early detection might prevent a house fire. Clever idea. Totally free to me. The insurance company is giving them away to policy holders.

@mfalkvidd said in Best PC platform for running Esxi/Docker at home?:

@NeverDie ...You can also use the command line tool fstrim to manually discard unused data.

Looking into this, I think checking the "Discard" box on the "Hard Disk" tab of the "Create a Virtual Machine" dialog box inside ProxMox may automatically accomplish the same thing. Also the ProxMox dataset that the VM is saved on needs to be set to thin-client. So, those two things plus the ssd emulation that you mentioned, and of course automatic file compression like lz4 needs to be enabled. So, in total, four things need to be set correctly for it to work optimally.

Originally I was concerned that because, if using ZFS as the file system, ProxMox only allows storing a VM as a pre-allocated "raw" file (rather than as a qcow2 file as ProxMox would if ProMox were using a linux ext16 file system instead of ZFS) that the file would take up enormous space even if the raw file (i.e. the VM's virtual disk) is mostly empty. So, I did the experiment, and it turns out that is true if the ProxMox dataset isn't configured as "thin-client" or if automatic file compression isn't turned on, but fortunately the true size of the raw file does indeed shrink down if those two conditions are enabled.

So, having proved that to myself, I'll pass on the tip: I now create a VM's disk to be as large as I can imagine it would ever need to grow, and then I let the thin-client mechanism maintain the true size of the virtual disk to be only as large as what is actually necessary. This way I don't have to worry that I created too small a VM disk, or that the VM will later outgrow the disk size that was originally allocated for it.