Hello @craigzyc, you can assign a prefered parent with #define MY_PARENT_NODE_ID n. If this should be the GW, set n to 0. If the node can't reach the parent, it will start looking for a new one and assign the closest repeater as the new parent.
I think what you are trying to do could potentially lead to some complex routes with many hops over time, if the connection to the GW isn't perfectly reliable and literally any node could be a repeater. In consequence, it might complicate debugging network issues, if there are so many routing options. So I'm not sure if this is a desireable setup.
Let's assume your location is a flat, plane space (so I can illustrate it better):
GW --- R1 --- R2 --- N1 --- R3 --- R4 --- R5 --- N2
AFAIK, messages to the GW are always routed through the parent of each node on the way. So if N2 (node without repeater feature) wants to reach the GW, but hasn't the GW set as its parent, it will route through the R (repeater) which answered its find parent request the fastest (propably the physically closest). So this might be R5 in this case.
R5 went through the same find parent process if it had trouble reaching the GW directly at some point, so it's possible that it relays all messages from N2 to R4. R4 to R3, and so on. There are up to six hops in this setup until the message from N2 reaches the GW. And on each hop something could go wrong. With each extension of the route, you are increasing complexity and reducing reliability.
IMHO, the better approach would be to make sure that each node itself is as reliable as possible instead of relying on a dense network. Use a good, stable power source, add capacitors to the transceivers to smooth the voltage level / reduce noise (e.g. 10 - 100 µF bulk electrolytic capacitor and 0.1 µF ceramic), etc. Test how reliable the signal in specific areas is (build a nRF24Doctor, run some tests with various capacitors or, monitor your network).
I'd suggest using only as many repeaters as you need and activate that feature on (always powered) nodes in one or a few central locations only.
Also, if range is a limiting factor at your place, consider using a different transceiver, like the RFM69. Due to the lower frequencies they use, you shouldn't need to use repeats at all, not even on large properties.
Today I finally found some time to put a few modules together.
A cheap solar cell (€1.35 a piece) with recharcheable battery which feeds via a step-up converter (€0.70 /pc) a pro-mini (5VDC). The DS18B20 is read every 5 minutes.
Now I’m Interested how long this sensor will do its job.
Thanks for the replies. I'll look into it. I'm not set on WIFI in any means, I do have zigbee, zwave, wifi so one of those would have been the most logical to jump off of, AND ill have plug-in power to all my sensor clusters. But also I do like the reliability of mesh-type systems than WIFI (have personally experienced how horrible those wifi bulbs are and those generally turned me off to WIFI but now WIFI looked to be my easiest entrypoint into DIY sensors (TCP/IP, UDP, ports, WPA this stuff I understand somewhat already). But I may prototype two different versions and see how mysensors meets my needs.
Thanks for your help. I'll do more reading.
Wow, I would have never thought that many either! Well done, guys.
I was satisfied when hek said we were above water, and should remain so foreseeable future. But thank you for the additional disclosure @tbowmo, I am sure anyone searching for such information will appreciate your forthrightness.
Recently came across this here: https://github.com/saghonfly/shrdzm/wiki. Seems to be an ESPNOW-based solution (MQTT-GW is also available).
Did no testing on that at all (I'm more tending to use wires/RS485 for homebrew stuff ), but if you are insisting in using these nasty Espressif-mcu's, this might be intresting...
@TRS-80 I looked at Grafana and InfluxDB a few years ago and found them supremely limited. It may be that I am a MS SQL Server user but the act if trying to do an update/delete of a value in InfluxDB is painful. Running everything through a JSON call to modify data annoys me.
So, all that aside I prefer sending data for long term storage to an instance of SQL Server 2012 - even with 4 sensor nodes + weather queries and some other data that send info every 30 seconds, 5 minutes, 10 minutes, and 30 minutes for a few years. I am not even above 100 MB of storage used. The data types are Date, INT, CHAR(xxxx), and in one crazy case VARCHAR(1000). I use Domoticz's built in sqlLite and hassio's DB to handle the data view from my controllers (yes, I have 2). The split of data occurs in Node-Red where it gets the data from my MQTT broker and sends to controllers (different subscription topics due to C/F fubaring in hassio) and send to SQL Server for long term storage. Efficient storage types is the key so a timestamp as an INT/BIGINT would be nice. As long as all your values are INT as well that is even better. Timeseries DBs do have their use, I have just not found one I like.
If there is a timeseries DB that can be accessed via ANSI SQL that would be awesome.
Other thought - you could use Elasticsearch to send in values as "documents" and then run analysis on them. For dataviz, I use the built in ones in my two controllers and I have written my own to handle long term data analysis. I prefer Highcharts for doing the viz as that is what I use at work. It is clean, efficient, and fully customizable.
