@projectMarvin He might have meant https://www.candlesmarthome.com.
There might be several other cloud-free open-source solutions for home automation. I personally use FHEM which "since ever" has been designed to run cloud-free and allow local control to virtually everything. (downside is: most likely as most (all?) other controller software offering a lot of options and allowing to control everything, you have to learn the underlaying language or at least a lot of specific commands/script instructions). Despite that, if you absolutely desire to involve one of the big internet players, it's possible to also add voice control options (to some extend also locally afaik; I' more focused on automation to overcome the needs for active user interaction).
Beside that: +1 to the statements of @projectMarvin .
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.
@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.
In general, yes, the MySensors framework (library?) should support FOTA a couple different ways (read more at link). Were you aware of this, or is there some problem with your particular hardware?
@NielBierman said in FOTA possibilities for remote sensor network:
I don't know yet whether you even need to change your gateway from microcontroller (uC) to Single Board Computer (SBC) or not. However if you do (or are looking for a controller, or whatever), by all means, please do yourself (and all of us) a favor and do a little more research as there are lots of better options out there for SBC nowadays, than RPi!
For me, uC have been fine for gateway although I do use some SBC for controllers, MQTT broker, and various other GNU/Linux based servers/services and they are wonderful for that. But perhaps your needs are different from mine.