@NeverDie Oh I've been running around 20 NRF52805 nodes for the past ~2 years https://forum.mysensors.org/post/108893. They've been working very well for me.
edit:
PRs to get working with mysensors
https://github.com/sandeepmistry/arduino-nRF5/pull/442
https://github.com/mysensors/ArduinoHwNRF5/pull/12
@mbedarff good question. Seems @CyborgAndy is keeping the addon alive? If so, @CyborgAndy are you publishing your changes to a public branch/fork?
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?
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.
@haloway13 I mean, last suggestion is restarting your openhab instance. If that doesn't work, please post your openhab log.
@electrik I believe NRF52832 and 51822 are the only supported NRF modules at this time. Some people have experimented and modified dependent libraries to get NRF52840 to work with MySensors but I'm not sure it's completely working and definitely wouldn't start there.
Personally, I like using the Ebyte NRF24 PA+LNA modules for my gateways and repeaters and use the NRF5 modules for end nodes.
I'm not even sure you can use NRF5 as a radio for a gateway, if so it might only work as a serial gateway.
As for additional items, I bought a jlink clone after having trouble unlocking ebyte modules with a STLink. Then my jlink clone caused issues (old firmware, not updatable) so I ended up buying a real JLink-edu.
Other things worth noting: there are a surprising number of hardware bugs with the NRF chips that mostly result in higher power consumption. General advice would be to stay away from NRF51822. EBYTE modules have been consistently reliable, high quality.
@haloway13 Can you post your sketch?
Your humidity sensor and your temperature sensor Thing configurations both point to Child Id = 0. I think your humidity sensor should be Child Id = 1.
@haloway13 progress!
Check the channels tab of your temperature sensor thing:
"Add link to item" then follow the directions to create a new item
@haloway13 Here are all of my settings in my sandbox environment.
A couple things to note, NO MQTT BINDING INSTALLED, no special MQTT thing configured, my mqtt install is not password protected.
My Gateway code:
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enables and select radio type (if attached)
//#define MY_RADIO_RF24
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95
#define MY_GATEWAY_MQTT_CLIENT
#define MY_GATEWAY_ESP8266
#define MY_BAUD_RATE 9600
#define MY_MQTT_CLIENT_ID "MYSGW01"
// Set this node's subscribe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "tele/mysgw01-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "cmnd/mysgw01-in"
// Set MQTT client id
// Enable these if your MQTT broker requires username/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"
// Set WIFI SSID and password
#define MY_WIFI_SSID "--------"
#define MY_WIFI_PASSWORD "*********"
// Set the hostname for the WiFi Client. This is the hostname
// passed to the DHCP server if not static.
#define MY_HOSTNAME MY_MQTT_CLIENT_ID
// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
//#define MY_IP_ADDRESS 192,168,178,87
// If using static ip you can define Gateway and Subnet address as well
//#define MY_IP_GATEWAY_ADDRESS 192,168,178,1
//#define MY_IP_SUBNET_ADDRESS 255,255,255,0
// MQTT broker ip address.
#define MY_CONTROLLER_IP_ADDRESS 192, 168, 1, 62
//MQTT broker if using URL instead of ip address.
// #define MY_CONTROLLER_URL_ADDRESS "test.mosquitto.org"
// The MQTT broker port to to open
#define MY_PORT 1883
// Enable inclusion mode
//#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
//#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
//#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
//#define MY_INCLUSION_MODE_BUTTON_PIN D1
// Set blinking period
//#define MY_DEFAULT_LED_BLINK_PERIOD 300
// Flash leds on rx/tx/err
//#define MY_DEFAULT_ERR_LED_PIN 16 // Error led pin
//#define MY_DEFAULT_RX_LED_PIN 16 // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN 2 // the PCB, on board LED
#include <ArduinoOTA.h>
#include <MySensors.h>
void setup()
{
pinMode(LED_BUILTIN, OUTPUT);
// Setup locally attached sensors
ArduinoOTA.setHostname(MY_HOSTNAME);
ArduinoOTA.onStart([]() {
Serial.println("ArduinoOTA start");
});
ArduinoOTA.onEnd([]() {
Serial.println("\nArduinoOTA end");
});
ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {
Serial.printf("OTA Progress: %u%%\r", (progress / (total / 100)));
});
ArduinoOTA.onError([](ota_error_t error) {
Serial.printf("Error[%u]: ", error);
if (error == OTA_AUTH_ERROR) {
Serial.println("Auth Failed");
} else if (error == OTA_BEGIN_ERROR) {
Serial.println("Begin Failed");
} else if (error == OTA_CONNECT_ERROR) {
Serial.println("Connect Failed");
} else if (error == OTA_RECEIVE_ERROR) {
Serial.println("Receive Failed");
} else if (error == OTA_END_ERROR) {
Serial.println("End Failed");
}
});
ArduinoOTA.begin();
}
void presentation()
{
// Present locally attached sensors here
sendSketchInfo("MYSGW01-TEST Gateway","1.0");
present(0, S_BINARY);
}
void loop()
{
// Send locally attached sensors data here
ArduinoOTA.handle();
}
void receive(const MyMessage &message)
{
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_STATUS) {
// Change relay state
digitalWrite(LED_BUILTIN, message.getBool() ? LOW:HIGH);
// Store state in eeprom
saveState(message.sensor, message.getBool());
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}
@haloway13 yeah, when you did the initial mqtt setup, did you protect it with a password? If not, make sure you clear out the username and password from the OpenHAB broker settings. (Iβm not sure if it will fail if you provide credentials to an instance that is not password protected)
also, is your MQTT broker password protected? if not, remove the username and password from your system broker configuration.
One thing I had to do was explicitly set secure="false" into /opt/openhab/userdata/config/org/openhab/mqttbroker.config.
Please try that, then restart.
Hmm, I don't use openhabian, but it looks like there is a log viewer built in: http://openhabian:9001 (maybe change openhabian to the IP of your pi).
Without logs or screenshots, it'll be impossible to help.
@haloway13 you have any logs or screenshots of errors you're seeing?
@haloway13 Looks good.
Next, I would get openhab ready for adding the mysensors addon. https://github.com/tobof/openhab2-addons/wiki/Installation
Via the openhab console run the following to install/activate the binding dependencies:
feature:install openhab-transport-serial
feature:install openhab-core-io-transport-mqtt
I recommend also setting log:set DEBUG org.openhab.binding.mysensors
Create a mqtt system connection in OpenHAB. Be sure to check advanced, and set the port.
Then you can drop the org.openhab.binding.mysensors.jar into the addons folder and it should auto install. You can start with the binding linked above.
Once all of that is done, you can configure your first thing, which would be a MySensors MQTT Bridge. (you should disable "Enables the startup check", I believe there is a bug)
@haloway13 Glad to see you're diving in.
Have you set up your gateway yet? If not, try this https://www.mysensors.org/build/raspberry. I find it's easier to build and debug node with a working gateway.
@TimO & @fabyte I took a stab at making all of the classes/interfaces @NonNullByDefault and adding/overriding null checks throughout. It builds fine, seems to be working well with my ethernet gateway.
I'm going to look at unit testing next.
@TimO Congrats!
I've been looking some of the other addon-ons and your code actually looks a lot better than most. I think the base is pretty solid.
I'll take a look at the annotations, and maybe getting some more traditional unit tests in place.
If we get to a point where a merge is acceptable, maybe we can move the maintenance fork to the MySensors repo.
@fabyte Nice work. I don't use mysensors-mqtt, but I do have a lot of tasmota devices using the generic mqtt binding.
I followed your directions to create system broker, then changed my existing mqtt broker connection to a "systemBroker" and referenced it by brokerid (Broker Name).
I had one other issue, the new system broker wouldn't start up. I had to manually add secure="false" to /opt/openhab/userdata/config/org/openhab/mqttbroker.config .
Maybe you can get away with toggling "Secure Connection?" a couple of times.
@fabyte this is helpful.
My intuition says the embedded mqtt broker and the generic mqtt binding create the same "mqtt" connection service behind the scenes. I'm guessing the generic mqtt binding isn't registering its service by name, or it's registering it by some other key.
I'd like to get the mysensors addon to work with both mqtt brokers if possible.
@fabyte I'd love to see this get pulled into the main repo. Not sure if @TimO plans to continue support, but I have no problem helping or even picking up where he leaves off.
I didn't contribute any MQTT specific fixes, and I don't recall manually migrating any MQTT fixes, but let me take a look.
Well, after a rather painful experience of manually upgrading and cherrypicking SerialPort changes from the decompiled OH3 mysensors jar posted above, I managed to get it a build working of the MySensors binding 3.1-SNAPSHOT.
This is the source: https://github.com/nikolac/openhab2-addons/tree/mysensors-oh3-migration/bundles/org.openhab.binding.mysensors
This fork has my addition, a direction channel on wind variables.
@TimO Great work.
I've had a merge request https://github.com/tobof/openhab2-addons/pull/141 floating around for months to add a wind direction channel to the my sensors binding.
Is your code in a shared repo? I'd love help add in my enhancement into your OH3 mysensors build.
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.
@martim Yep, you just need to make sure to turn off the EEPROM module after setup, then it's basically an Atmega328p and NRF24L01+. It has solderable jumpers to bypass the voltage regulator and status LED.
Here is a claim of 12uA in sleep: https://forum.mysensors.org/post/96631
@martim I think this is a better alternative: https://www.electrodragon.com/product/nrf24duino-arduino-mini-plus-nrf24l01-board/
@NeverDie Currently using 6, [GND, VCC, SWDIO, SWCLK, - , TX, RX, -, -, -]
Sensor node on the left, button node on the right.
Playing around with enclosure designs for my new node
@sundberg84 I noticed similar issues with my nodes. Given the high internal resistance of coin batteries, there is actually a significant voltage drop during high current scenarios (radio transmission). Enough of a drop to trigger brownout, which then leads to brownout loops.
I recommend disabling status LEDs, and using large capacitor(s) (200uF+), ideally ceramic. I'd also drop BOD to 1.8v.
Also make sure you're sleeping between transmissions (~5 sec) to make sure the capacitors have enough time to recharge.
@berkseo Thank you!
First, I made the compatibility changes to SandeepMistry. This was surprisingly easy. The SDK in SandeepMistry/nRF5-arduino does most of the heavy lifting. I had to modify a few of the precompiler conditions to exclude PWM, change some serial definitions, and update to new handler naming conventions: https://github.com/sandeepmistry/arduino-nRF5/pull/442
Then, I defined a new Generic NRF52805 variant in mysensors/ArduinoHwNRF5 and handled one assumption of LPCOMP: https://github.com/mysensors/ArduinoHwNRF5/pull/12
Last, I had to handle a few small assumptions in the MySensors library: https://github.com/mysensors/MySensors/pull/1461
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:
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.
This is a great breakdown of the TP5000 charger.
https://lygte-info.dk/review/Review Charger TP5000 4.2-3.6V module UK.html
@willemx I believe below 3.3v it will basically pass through the input voltage with a minor drop, less than 0.2v. I also just tested this at 1.8v in the output is 1.787v (no load)...so not bad.
I use the XC6206 more often.
@willemx I have a MySensors weather station powered by a 5.5v solar panel, TP5000, and a AA LiFePO4 that has been running for 2 years.
I also have a couple of soil sensors with a similar set up. It's been very reliable.
If you take the battery out while the TP5000 + solar panel is still connected, I believe it will pulse 3.2 - 3.6v into your board. I would recommend using a HT7333 or XC6206 voltage regulator and a large capacitor, just in case.
You don't need to be super concerned with power efficiency. I find my small solar panel tops off the battery within the first hour of indirect sunlight.
@Didou Which NRF5 module are you using exactly?
I also believe this code from your sketch is unnecessary, given MySensors handles most of it:
void nRF_Init() {
NRF_POWER->DCDCEN = 0; // Not reducing the radio current
NRF_PWM0 ->ENABLE = 0;
NRF_PWM1 ->ENABLE = 0;
NRF_PWM2 ->ENABLE = 0;
NRF_TWIM1 ->ENABLE = 0;
NRF_TWIS1 ->ENABLE = 0;
//NRF_RADIO->TXPOWER = 8;
}
void disableNfc() {
NRF_NFCT->TASKS_DISABLE = 1;
NRF_NVMC->CONFIG = 1;
NRF_UICR->NFCPINS = 0;
NRF_NVMC->CONFIG = 0;
}
void turnOffAdc() {
if (NRF_SAADC->ENABLE) {
NRF_SAADC->TASKS_STOP = 1;
while (NRF_SAADC->EVENTS_STOPPED) {}
NRF_SAADC->ENABLE = 0;
while (NRF_SAADC->ENABLE) {}
}
}
@Didou for my testing, I pulled the entire branch referenced in the merge request. I believe that is MySensors-development + nrf_esb_redesign changes. But you're probably safe to just replace the two files touched in the commits.
@Didou There is currently a bug in the NRF5 transport layer that causes them to lock up. It seems more likely to happen when the connection between the gateway/repeater is weak or too far.
You can read more about it here: https://forum.mysensors.org/post/108301.
My understanding there is a fix pending review and @waspie has been testing it with some NRF51822 modules.
@Avamander That would make a great gateway. I believe I read a getting started guide by the creator of that Pi Hat, Playing with Thread and MQTT-SN on Nordic nRF52840. The tutorial is a little outdated now, but it's a good overview of the process of setting up a Thread network. There is a lot of good content on that blog.
I agree, but it is still not clear to me what the appropriate relationship between MySensors and OT / BLE Mesh is. It seems there is a lot of overlap in functionality. While I prefer to focus on the NRF5 series, a majority of the community is using ATMEGA328 and NRF24, or LoRa modules, which wouldn't support OT / BLE.
At the very least, I'd like to see MySensors tap into some more of the advanced NRF5 capabilities: OTA, NFC.
There are also a few examples of NRF5 modules running in dual mode: BLE + OT. If it's possible to run 2.4GHz + BLE in parallel, then there is potential to create a MySensors bridge device.
Or maybe leveraging BLE to configure MySensor nodes at runtime: modifying sleep duration, send frequency.
Given the abundance of storage and memory on the NRF5 devices, it is also feasible to create something like Tasmota / ESPeasy for MySensors. Use the same firmware on every node, have the MySensors gateway/controller manage and push configuration templates. Given the great work on MySensors NodeManager and the SmartSleep functionality, it seems like the foundation is already in place.
@NeverDie Thanks, and good call on the Ebyte NRF24 with LNA. I have a few laying around that I've been meaning to incorporate into a generic multi-sensor gateway/repeater node. If they're always connected, might as well collect environment data and maybe motion too.
Update on my NRF52805 Breakout:
Just need to test SPI and figure out a clever name for the board, and should be good to go.
@NeverDie I spent the last week really deep diving into NRF BLE & NRF networking capabilities.
Some things I learned:
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....
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:
If all goes well, I'll submit the merge requests and publish this board schematic on openhardware sometime in the next week.
@waspie Looking a lot better. This node is in the same location that it was before the update?
@waspie ...potentially. It's a little confusing, to be honest.
I used #1448 based on this comment in #1445 (the revision commit).
@waspie I haven't tried the code from the redesign branch, as there are a lot of additional enhancements that may not have been fully tested yet.
I've been testing this file on NRF52s, hal/transport/NRF5_ESB/driver/Radio_ESB.cpp, specifically from this commit https://github.com/mysensors/MySensors/pull/1448/files.
Given the redesign merge request was submitted a few days after this Fix ESB deadlock, the Fix ESB Deadlock might not be that effective. I haven't been testing on NRF51.
I'd suggest asking on github, as a comment on the NRF5 ESB redesign commit, for suggestions on the best way to test the latest improvements.
I think it's a symptom of the "deadlock" scenario. I had a similar experience with NRF51 soil level sensors that were on the edge of their usable range. Looks like they get stuck in a loop, drain a huge amount of power (these were AA and AAA LiFePO4), trigger undervoltage/brown out, then restart, effectively clearing the deadlock.
I'm guessing that high interference or weak signal (too far away) increases the number of transmission attempts, compounding the likelihood of lockup.
@waspie Thanks for sharing. First thing I notice is you can probably remove:
NRF_CLOCK->INTENSET=B11;
NRF_CLOCK->TASKS_HFCLKSTART=1;
while (!(NRF_CLOCK->EVENTS_HFCLKSTARTED)) {}
from your setup(). I believe this is legacy code that is now built in to MySensors / nRF5-arduino, and managed based on the features you're utilizing.
I just tested power consumption on NRF51822 with SI7021. Similar to your sketch but using the LowPowerLab SI7021 library.
I didn't have to do any hack or workaround to get ~7uA power consumption.
I'm using MySensors 2.3.2, SandeepMistry/nRF-Arduino 0.6. Just to be sure, I also reburned the bootloader.
I will try to get your sketch running on my NRF51, see if I can rule out the specific library as a cause for your power issues.
#define MY_RADIO_NRF5_ESB
#define MY_NODE_ID 68
#define MY_PARENT_NODE_ID 13
#define MY_PARENT_NODE_IS_STATIC
#define MY_PASSIVE_NODE
#define MY_TRANSPORT_UPLINK_CHECK_DISABLED
#define MY_TRANSPORT_CHKUPL_INTERVAL_MS 2000
#define MY_TRANSPORT_WAIT_READY_MS 1000
#define MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS 2000
#define SLEEP_SHORT_MS (5000)
#define SLEEP_MS 1000 * 60 * 1
#define REBOOT_HRS 24
#define REBOOT_MS 1000 * 60 * 60 * REBOOT_HRS
#define BATTERY_SEND_MS REBOOT_MS
unsigned long sleepTime = BATTERY_SEND_MS;
unsigned long lastReboot = 0;
unsigned long lastBatterySent = 0;
unsigned long lastTemperatureSent = 0;
bool firstBoot = true;
#include <MySensors.h>
#include <SI7021.h>
MyMessage msgBattery( 1, V_VOLTAGE );
MyMessage msgTemperature( 3, V_TEMP );
MyMessage msgHumidity( 4, V_HUM );
static SI7021 sensor;
void setup() {
enableReset();
sensor.begin();
}
void loop() {
bool sendBattery = millis() - lastBatterySent >= BATTERY_SEND_MS || firstBoot;
bool shouldReboot = millis() - lastReboot >= REBOOT_MS;
const float temperature = float( sensor.getFahrenheitHundredths() ) / 100.0;
const float humidity = float( sensor.getHumidityBasisPoints() ) / 100.0;
sleep(SLEEP_SHORT_MS);
send( msgTemperature.set( temperature, 2 ) );
sleep(SLEEP_SHORT_MS);
send( msgHumidity.set( humidity, 2) );
if(sendBattery){
sleep(SLEEP_SHORT_MS);
bool sent = send(msgBattery.set(getInternalVoltage(),3));
if(sent) lastBatterySent = millis();
}
if(shouldReboot){
lastReboot = millis();
hwReboot();
}
firstBoot = false;
sleep(SLEEP_MS);
}
void present() {}
float getInternalVoltage(){
return ((float)hwCPUVoltage())/1000.0;
}
void enableReset(){
NRF_POWER->RESET = 1;
while (NRF_POWER->RESET != 1);
}
@skywatch that's good to know, thank you
I want to extend the footprint pads beyond the edge of this non-castellated nRF5 module, so that I have a chance to hand rework any soldering issues. Is this bad practice? Will the solder mask on the module cause issues?
Appreciate any feedback, thanks.
@waspie Mind sharing your sketch?
I've run into a few issues with NRF51 modules:
Issues with all NRF5 modules:
@waspie Looks like there is a related issue with NRF51822
#35 in https://infocenter.nordicsemi.com/pdf/nRF51822-pan_v2.0.pdf?cp=5_4_1_8
But I don't think you'll need to do hack I listed above (not sure it'll even work for NRF51822). You can probably replace the three lines above with
NRF_TWI0->ENABLE = 0;
NRF_TWI1->ENABLE = 0;
Just be sure to call Wire.begin() before each sensor read. Or if you're using a library, make sure you call the service that calls Wire.begin(), in my case that was sensor.begin().
I'll try with one of my NRF51 modules tomorrow and report back.
@NeverDie said in nRF5 action!:
https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/bluefruit-nrf52-api
Ha, I ordered one yesterday. I'll mess around and report back.
@monte thanks
I'm struggling with choosing the direction of the next steps in my diy sensor journey.
My focus has moved exclusively to nRF5 boards given the compact size, performance, and cost. I don't have range, penetration, or interference concerns, so I don't utilize any of the LoRa support in MySensors.
Given the ubiquitous support of BLE, recent advancements in mesh and long range capabilities, continued investment, widespread adoption...it might make more sense for someone with my use case to explore moving to a BLE based network.
I'm assuming there isn't much to gain by layering MySensors on top of BLE. And I'm not sure it makes sense for the MySensors community to expand and maintain support for boards capable of MySensors use, but primarily intended for BLE use. Especially, considering a significant majority of the community is completely satisfied with ATMEGA + (NRF24 / LoRa).
Well, adding
*(volatile uint32_t *)0x40004FFC = 0;
*(volatile uint32_t *)0x40004FFC;
*(volatile uint32_t *)0x40004FFC = 1;
just after the Si7021 sensor reading worked. Sleep current is back down to 12uA.
https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev1/ERR/nRF52832/Rev1/latest/anomaly_832_89.html#anomaly_832_89
Probably not the best place for it. I think it should probably live in TwoWire:end() https://github.com/sandeepmistry/arduino-nRF5/blob/8f41ab685197bfc27b56705ee8a7f63f653344ae/libraries/Wire/Wire_nRF52.cpp#L132
Working code
#define MY_NODE_ID 67
#define MY_RADIO_NRF5_ESB
#include <MySensors.h>
#include <SI7021.h>
static SI7021 sensor;
#define SLEEP_SHORT_MS (5000)
#define LED_INFO_PIN (5)
#define SLEEP_MS (30000)
MyMessage msgHum( 4, V_HUM );
MyMessage msgTemp( 5, V_TEMP );
void setup() {
pinMode( LED_INFO_PIN, OUTPUT );
blink(LED_INFO_PIN, 5);
}
void present() {}
void loop() {
blink(LED_INFO_PIN, 1);
sensor.begin(); //needs to be reinitialized after hack to disable
const float temperature = float( sensor.getFahrenheitHundredths() ) / 100.0;
const float humidity = float( sensor.getHumidityBasisPoints() ) / 100.0;
*(volatile uint32_t *)0x40004FFC = 0;
*(volatile uint32_t *)0x40004FFC;
*(volatile uint32_t *)0x40004FFC = 1;
sleep(SLEEP_SHORT_MS);
send( msgTemp.set( temperature, 2 ) );
sleep(SLEEP_SHORT_MS);
send( msgHum.set( humidity, 2) );
sleep( SLEEP_MS );
}
void blink(uint8_t led, uint8_t count){
for(int i = 0; i < count; i++){
digitalWrite( led, HIGH );
wait( 5 );
digitalWrite( led, LOW );
if( i < count - 1 ) wait(100);
}
}
Looks like it's probably related to this: https://github.com/sandeepmistry/arduino-nRF5/issues/291
@NeverDie I see.
Say the Arduino mbed route supports my nRF module, would MySensors library need to be rewritten? Any idea how coupled it is to the sandeepmistry core?
Before exploring compatibility, I ordered a few nRF52805 modules from Ebyte, but I'm still waiting on delivery https://www.aliexpress.com/item/1005001709688444.html
Any way to know if NRF52805s are compatible with the current core, sandeepmistry/arduino-nrf5? With MySensors?
https://infocenter.nordicsemi.com/topic/struct_nrf52/struct/nrf52.html?cp=4l
What is the hypothetical process of adding a new NRF52 variant? Where would I start?
Sleep power consumption for my ebyte E104-BT5032A module is ~12uA with the Si7021 module connected and powered, but I'm seeing that jump to ~460uA when I include SI7021.h and actually communicate with it.
I'm assuming that the Wire library is turning on features that are not powered down after communication or before sleep?
SI7021 library manually included from: https://github.com/mysensors/MySensorsArduinoExamples/archive/master.zip
#define MY_NODE_ID 67
#define MY_RADIO_NRF5_ESB
#include <MySensors.h>
#include <SI7021.h>
static SI7021 sensor;
#define SLEEP_SHORT_MS (5000)
#define LED_INFO_PIN (5)
#define SLEEP_MS (30000)
MyMessage msgHum( 4, V_HUM );
MyMessage msgTemp( 5, V_TEMP );
void setup() {
pinMode( LED_INFO_PIN, OUTPUT );
while(not sensor.begin());
blink(LED_INFO_PIN, 5);
}
void present() {}
void loop() {
blink(LED_INFO_PIN, 1);
const float temperature = float( sensor.getFahrenheitHundredths() ) / 100.0;
const float humidity = float( sensor.getHumidityBasisPoints() ) / 100.0;
sleep(SLEEP_SHORT_MS);
send( msgTemp.set( temperature, 2 ) );
sleep(SLEEP_SHORT_MS);
send( msgHum.set( humidity, 2) );
sleep( SLEEP_MS );
}
void blink(uint8_t led, uint8_t count){
for(int i = 0; i < count; i++){
digitalWrite( led, HIGH );
wait( 5 );
digitalWrite( led, LOW );
if( i < count - 1 ) wait(100);
}
}
I should add that I haven't tried PCB milling yet. I mostly try to make aluminum parts with my 3040 machine.
@NeverDie Once covid started, my aliexpress luck really took a dive. Two missing shipments, one partial shipment, and very little recourse. If I absolutely have to, I'll buy from banggood. I don't think I would make such an expensive purchase on aliexpress, especially when shipping is a significant portion of the cost. OR, I would want to talk to somebody who has purchased from that seller and has the exact product I'm looking at.
Contrary to my 3D printing and PCB/component experience, where I do okay with cheap/counterfeit parts, the tolerances and high cost of mistakes in my CNC experience are leading me to pay the premium for quality parts.
@NeverDie Mind posting links to the spindles you're looking at?
Compact, simple NRF52 motion sensor
Ebyte E104-BT5032A NRF52832 module
MH-SR602 Motion Sensor
LiFePO4 AA Battery
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.
@mfalkvidd Yeah, I realize I can only use a portion of the strip, or keep it very dim. I actually bought this with the hopes of flashing with Tuya Convert, but turns out they switched to non ESP modules. So, I figured I would make my own.
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.
@berkseo Very nice. I wasn't aware that MySensors was working on NRF52840. Any different than the NRF52832 when it comes to flashing bootloader, uploading sketches, or executing code?
@berkseo said in What did you build today (Pictures) ?:
Π‘apacitive touch button - V1.0 β 02:09
β Andrew EfektaSB
Looks really good! I like the LED bridge.
@NeverDie Buttons -> Mysensors Gateway -> OpenHab Rules -> Tasmota Switches / Outlets / Extension cords.
I am tempted to explore the BLE route. It seems to support a majority of my sensor use cases, I like the idea of standardizing on the GATT protocol, and there are already a ton of tools and connectors in place.
My super simple NRF51 touch buttons. I mostly use these to toggle overhead lights that I've converted to Tasmota.
With all the NRF52 modules from EBYTE I've tried, the only way I can flash them is over SWDIO, SWCLK, GND, VCC via JLink clone.
And, before flashing is possible, I have to unlock the module by following these directions: https://github.com/micooke/arduino-nRF5-smartwatches/blob/master/nrf52_disable_read_protection.txt
@Joost For the price, this could be a simple way to start
https://www.electrodragon.com/product/atmega328p-arduino-plus-lora-sx1278-board-loraduino/, though it's not exactly what you're asking for.
@p359 Which version of Arduino IDE are you using? I was seeing that with 1.8.10, but I ended up downgrading to 1.8.6 to test and it worked.
@neverdie Yeah, I think starting a dedicated thread is the right move.
That sounds a lot like what I'm trying to do. Prioritize load (boot/transmission) power, then dump into a reserve. This make sense when light is strong, but when solar isn't producing, how do you get power from the reserve to the load capacitors. Would you boost it?
@neverdie said in 
Effective Solar Supercap Boost Charger for Small Solar Panel:
@ncollins Here's the load switch that I've been using: http://www.ti.com/product/TPS22860 I like it a lot. I think it, or something similar, should be in everyone's tool box.
Awesome, I'll order a few. Appreciate the info, thanks.
@neverdie yeah, the fixed hysteresis of the internal BOD (328p, NRF51) isn't wide enough to handle startup for my nodes. I'm guessing it's due to the high ESR and corresponding voltage drop of the supercaps I've been favoring.
I also didn't realize how chatty mysensors can be during start up. My latest nodes have MY_PASSIVE_NODE enabled, skip presentation, and use dumb sleep.
@neverdie With all of your energy harvesting approaches, how are you handling unforeseen restarts? Almost all of my harvesting sensors have the same issue: if they drop below 1.8v (depending on BOD) they can't recover without manual intervention. Only one of my nodes has ever recovered and I think it's because the solar panel produced enough current to push through the MCU and radio startup.
My thought was to use the MIC2778 supervisor ic (datasheet), which has programable hysteresis, and a mosfet to wait for supercap/battery to reach a voltage high enough to handle a cold start.
@neverdie It's mostly because I haven't figured out how to appropriately, efficiently handle the wide voltage range of the 3722s.
In ambient light, they'd be perfect, but most locations in my house, there's a chance they'd get hit with direct sunlight. In a couple of my earlier prototypes, I fried the NRF module after the supercap exceeded 3.6v (damaged something that causes them to draw ~1-2ma).
In my case, I don't have a lot of artificial lighting, but I do decent direct/indirect sun from windows for at least part of the day.
Thoughts:
I'm mostly avoiding the issue by using the SC-3517s. A single cell wasn't really cutting it unless in direct sunlight, so I double up in parallel.
Bonus: other prototypes
Uses your boost charger
Testing out 50mF low ESR super cap
@neverdie at ~$1.90 per keychain, seems like a great way to get into harvesting.
I bet it would be easy enough to design and 3d print a replacement to the button half of the housing with a little more space for a radio and sensors.
I mean, you could probably just add an LDO, HT7333 or XC6206, and use it as is.
I've tried a lot of the aliexpress modules.
My experience with cheap modules
@waspie Given that all of my interrupt nodes stopped triggering after 36 hrs (before your reboot workaround), it has to be related. Itβs just weird that my nodes would continue to wake up and broadcast battery level.
Is the LPCOMP interrupt method dependent on the wdt? Maybe resetting/restarting the wdt every 24hrs would suffice? Or maybe you have to reactivate LPCOMP every 36 hr wdt cycle?
@neverdie In theory, indoor is optimized for visible light spectrum. Outdoor, a combination of visible and IR. https://www.powerfilmsolar.com/about-us/the-horizon-blog/2018/08/10/outdoor-vs-indoor-solar-the-key-differences
But, who knows with these chinese panels. I haven't tested the indoor vs outdoor side by side. I do know these amorphous "outdoor" panels work significantly better indoors than the mono/polycrystalline panels I have.
@neverdie Awesome. Interested to see how they work out for you.
For other options, this is the only retail outlet I've been able to find that carries different size/volt versions of the chinese amorphous panels.
https://cnmarsrock.aliexpress.com/store/group/Amorphouse-solar-panel/400691_511437499.html
@waspie just to follow up, 24hr reboot() is working perfectly. Appreciate the help.
@neverdie I used tantalum because they were laying around and I was too impatient to wait for the 1206 100uf ceramic caps I had ordered.
Those are definitely interesting. The high ESR on the lower capacitance coin-cell "H-type" 0.47F super caps caused a voltage drop significant enough to trigger brownout on my first few nodes.
I was hoping to try these out, but they seem to have been discontinued https://www.mouser.com/new/Murata/murata-dmh-supercaps/.
@neverdie I've primarily been prototyping with the SC14351 because I don't have to worry about voltage regulation when coupled with supercaps.
@neverdie In direct sunlight, I've seen 5.5v at around 4ma.
These seem to be the cells SC-3222-9 SC-3722-9 (edited).
http://www.vimun.cn/en/ProductInfo.asp?pid=17