My super simple NRF51 touch buttons. I mostly use these to toggle overhead lights that I've converted to Tasmota.

@NeverDie I spent the last week really deep diving into NRF BLE & NRF networking capabilities.

Some things I learned:

• BLE is a great way for low power communication with a dedicated, physically close parent node
• BLE alone does not establish a network, just a link to a central/gateway node. Giving the limited range, that means having multiple gateways, and dedicated links (painful, inflexible)
• That led to the creation of BLE Mesh. I found this article from Integra Sources to be really helpful as they talk through the real world limitations they experienced trying to go to production with it. In summary, BLE Mesh is a "managed flood" which quickly leads to network storms if not optimized
• Then I found OpenThread
  
• After messing around for few days, I found this guide https://github.com/kyberpunk/openthread which really simplifies getting started. Two docker containers: OpenThread Border Router (sensor network gateway) and MQTT-SN (UDP6 MQTT bridge to MQTT Broker). I was able to setup a network with two NRF52840 dongles + NRF52840 DK, and post messages to my MQTT instance within a couple of hours.

OpenThread is supported on the the NRF52840, NRF52811, NRF52833, as well as 10-15 chips from other vendors.

I really like the ability to route via IP and the fact that all of the nodes communicate with common, well known protocols. I like the secure-by-default approach, and the built in tools for administering networks (commissioning new nodes).

I'm going to keep exploring this route, seems promising....

A bed occupancy sensor. 4 50kg load cells, an HX711, and a Wemos D1 to make a wifi scale that rests on a bed slat under the boxspring.

Given the placement and weight distribution it doesn't turn the bed into a huge bath scale, but definitely accurate enough to use the deltas to estimate if there is someone in the bed. I can also tell when our 12lb (5.5kg) dog is on the bed.

I have rules in openhab to turn the overhead fan on and off. Also disables some TTS notifications if somebody is in bed.

Just started testing my new NRF52805 breakout board. I added a new generic variant to sandeepmistry/arduino-nRF5, added a new board to mysensors nRF5, now I'm testing compatibility.

This new NRF52805 chip is interesting. Way stripped down compared to the rest of the NRF5 line. No PWM, no LPCOMP, only 10 GPIO (maybe 8 usable).

But, it's cheap, ~$2.50 for the EBYTE BT104-BT5005 module, compact, and appropriate for most low-power use cases.

Interestingly, the chip does not support the current MySensors default, but deprecated, data rate of 250Kbps. Today I also learned that modules can only communicate on the same data rate. So I created a ESP8266 + NRF24L01+ gateway at MY_RF24_DATARATE RF24_1MBPS, and it worked!

Still need to test a few things:

• I2C
• SPI
• Power consumption

If all goes well, I'll submit the merge requests and publish this board schematic on openhardware sometime in the next week.

Compact, simple NRF52 motion sensor
Ebyte E104-BT5032A NRF52832 module
MH-SR602 Motion Sensor
LiFePO4 AA Battery

First attempt at a modular NRF52805 based board. The smaller board has a Si7021 temp + humidity sensor and a BH1750 light level sensor, both I2C. Ideally, I should be-able to make other sensor boards with the same footprint as long as the sensors are I2C.

Also included:

• CR2032 Battery (~1.5 years between battery changes)
• 10P 0.5 FPC connector for programming and serial debugging
• 2 LEDs with solderable jumpers
• On/Off switch (I find this really useful, especially when fighting with coin batteries)
• RST button
• Secondary button that I use to force immediate readings
• Footprint for centered button for alternative use as a remote button (my most common MySensors node)

I'll post pictures of the enclosure when it's ready.

I'm also waiting on delivery of a slightly larger version of this board that holds a 2477 battery and a SMD PIR motion sensor.

The latest addition to my coin cell nodes, a PIR motion sensor based on the Ebyte NRF52805 module.

The PIR sensor is a Senba S16-L221D-2. I'm measuring around 24uA, which is higher than advertised, but with the 6-7uA from the NRF52805, should still get me 3-4 years on a single 2477.

@neverdie Yep, I had the same experience with this LTC3108 breakout.
https://www.aliexpress.com/item/LTC3108-1-Ultra-Low-Voltage-Boost-Converter-Power-Manager-Breakout-Development-Board-Module-Diy-Kit/32867270266.html

I also intended to try the following modules which have a ton of functionality baked in. Unfortunately, they multiply the cost of a basic node by 2-5x.

BQ25570
https://www.aliexpress.com/item/32903287631.html

BQ25504
https://www.aliexpress.com/item/32976994195.html

From an energy harvesting perspective, I think rechargeable watch battery + 0.2F super cap + 4 100uf is my favorite setup. Cheap, fault tolerant, very small profile if you use 1206 ceramic capacitors (not shown in this prototype). Based on this design: https://www.allaboutcircuits.com/technical-articles/overview-of-the-ble-solar-beacon-from-cypress-semiconductor/

0.2F 3.3v Capacitors
https://www.aliexpress.com/item/32577753501.html

3v Rechargeable Battery
https://www.aliexpress.com/item/32813917590.html

1206 100uf Capacitors
https://www.aliexpress.com/item/32376068793.html

Cheapest amorphous, indoor solar panels I have found: 2.7-3v
https://www.aliexpress.com/item/1854641441.html

Tiny S4 1N5817 Diodes
https://www.aliexpress.com/item/32813213875.html

USB + ESP8266 adapter for W2812B LED strip.

Well, this is actually a Tasmota + Openhab build, but could easily be MySensors.

Also worth noting, this 5m 150 led strip draws too much current to reliably use with a USB wall adapter.

@neverdie according to a few datasheets 2v at 200lux. The solar cells delivered were HENGYANG SC-3514.

http://www.vimun.cn/en/ProductInfo.asp?pid=18
http://www.solars-china.com/solars/indoor-solar-cells.pdf

On my windowsill, 2.5v typical in-direct sunlight, 2.7v is the highest I've recorded in direct sunlight.

So far, most of my Aliexpress buys have been fine for my needs. Haven't really gotten close to making a "production ready" module, so for prototyping it's been fine.

One exception: I thought I had a genius idea to repurpose these $1 solar powered keychain flashlights. They had an amorphous solar panel, rechargeable battery, button, leds and a housing...for $1. I bought 20 of them. First one I opened up, I realized it's a lie!

The solar panel is just glued to the circuit. The battery is just a normal non-rechargeable CR2016.

What are you trying to do? Remotely control store-bought solar lights?

@Jon-Raymond Well, not seeing a lot of activity in the repo.

I took a very long shot at adding support https://github.com/nikolac/arduino-nRF5/tree/nrf52805-s112-support.

I was able to flash the softdevice, but I haven't tested or even uploaded a working sketch (sloppy). Feel free to mess around and test. If it works for you, I do the same for S113.

Biggest question I have is around figuring out the proper values for the "linker scripts" https://github.com/nikolac/arduino-nRF5/blob/nrf52805-s112-support/cores/nRF5/SDK/components/softdevice/s112/toolchain/armgcc/armgcc_s112_nrf52805_xxaa.ld

@Jon-Raymond the nRF52805 should support the S112 and S113 soft device, but I removed it from the menu because I never tested it and didn't intend to immediately use it.

Digging through sandeepmistry/arduino-nrf5, it looks like S112 and S113 aren't included in the SDK. It might be easy enough to just drop in two new folders, then update boards.txt.

(Just an example of how I would add a soft device option to the dropdown, these would have to match up with whatever is in the sdk)

I would recommend opening an issue/question on https://github.com/sandeepmistry/arduino-nRF5, specifically asking the best way to add a new softdevice to the library. If it's straightforward, I can work with you to get those changes incorporated and, hopefully, included in the merge request.

@Jon-Raymond I pushed my latest changes, posted a question to the merge about next steps.

@Jon-Raymond I kinda got hung up on the last conversation in the merge request and haven't looked at it since. Let me push the changes I have to address the other comments, then try to figure out how to best handle that last bit.

@MDS I looked into this a bit after seeing the same double message in the log. You have ACK setup for these nodes? In the mysensors binding code, it looks like the bridge sends a message then waits for an ACK, and resends if it doesn't get the ACK within a specific amount of time. Unfortunately, it looks like it waits 0ms for the first ACK (doesn't wait) and automatically retransmits = guaranteed duplicate sent. It hasn't really caused any problems for me.

As for the dropped messages, do you have a delay set up on your bridge config [sendDelay=200]?

Can you post your arduino code?

No docker expert here, but I think docker-compose is intended to provide the functionality of logically grouping containers/dependencies, as apposed to combining products in a single container.

It could definitely be helpful to maintain a few home automation compose "templates." For example, my template would be: OpenHAB, InfluxDB, Grafana, mosquitto.

@haloway13 I really don't have an understanding of how it works. I'm not sure how OpenHAB knows when to convert a value from a sensor reading?

• When you set the platform level metric/imperial setting, is that establishing the assumption that all sensor values are metric/imperial?
• If the metadata override for a Number:Temperature doesn't match the platform setting, is openhab smart enough to do the conversion?
• When updating the metadata, does that convert the current value or only updates after setting the metadata?

In my limited experiments, changing the metadata just seems to change the label suffix to ˚C or ˚F

@haloway13 oooof, I found that to be confusing too.

If your platform settings Settings -> Regional Settings [advanced] -> Metric / Imperial are set,

and you define your items as Number:Temperature, they should "magically" display in the correct format and auto converted, but I've had a lot of trouble with that.

There are also settings to have the gateway confirm "isMetric" and have you node respond in the appropriate unit.

Lastly, in your item definition, you can "Add Metadata" -> State Description, and set a display format that supposedly converts value, but I'm not sure I understand exactly when it's suppose to override platform settings.

More info here: https://community.openhab.org/t/solved-the-right-place-to-do-temperature-conversion/91233

@haloway13 Yes!! Impressive perseverance.

Somehow I've become emotionally invested in your outcome, so this is extremely satisfying. Great work.