General Discussion

@mfalkvidd was part of the sketch. I could see right away that sleep did not work :)

@mrhutchinsonmn no prob! Glad I could help.

Thanks for explaining @mrhutchinsonmn

@ady_e_n Presumably a low current DPDT switch. Since I have them anyway I'd be using a latching DPDT signal relay fired by two logic level mosfets controlled by two pins, hence emulating the switch itself with no running current. The relays I have are NEC EE2-3TNU around 7mm thick and 9mm tall, 5v version should be available if that is your logic voltage level. If space permits you could hot glue the relay to the board on it's side with the mosfets/resistors/3 pin control mounted onto it's base, hard wired to the original switch pads. ;)

@eiten support for multiple radios is a new feature, only available in the development branch and not well documented yet so no surprise you weren't aware of it.

@cloolalang Actually, I'm tempted to try the SX1280. It's a lot more different: https://forum.mysensors.org/topic/11265/second-setup-choosing-a-radio/34?_=1595815545926 It looks as though a "good enough" test drive library may possibly already exist: https://github.com/StuartsProjects/SX12XX-LoRa The same person range tested it and also did a thoughtful review: https://github.com/StuartsProjects/SX1280_Testing Paraphrasing, he says it lends itself to a more simplified programming style than the highly register centric approach of the SX127x's. Spoiler: he proves a range of 40 kilometers transmitting at just 4dB. He estimates a range of 200 kilometers should be possible. Impressive for such a modest little module: [image: IMG_2517_Reduced.jpg] Sounds interesting!

Has anyone bought a PineTime by chance? They are really progressing quickly, with OTA support and everything.

@scalz Thanks.

@cloolalang said in LoRa/RFM95 - Testing long range PHY settings - Findings: w the SF 12 long payload messages pass! I tested various SF and BW and coding rates, I decided on the following for the "long-range mode". Typical use will be point-point mode, or gateway to 2 or 3 nodes max, no repeaters. Horizontal polarised yagi antennas. MY_RFM95_FREQUENCY 433237500ul (its 1MHz away from my co-located standard mode gateway frequency and other local ISM users). RFM95_MODEM_CONFIGRUATION RFM95_BW62_5CR45SF4096 (Typical time-on-air is around 4000ms. MY_RFM95_ATC_MODE_DISABLED (to reduce traffic). How is testing going on this? I'm interested to know what sort of distance you can cover, I'm planning on some long range sensors to be deployed on my farm. I'm not quite gettting the range I would like. Here is the radio config in my current setup, but I will definitly look at some of the additional config that you have. #define MY_RFM95_FREQUENCY (RFM95_868MHZ) #define MY_RFM95_MAX_POWER_LEVEL_DBM (100) #define MY_TRANSPORT_STATE_TIMEOUT_MS (3*1000ul) #define RFM95_RETRY_TIMEOUT_MS (3000ul) #define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096 As a matter of interest has anyone used repeater nodes with these sort of long range setups. I'm talking about distances over a KM with no clear line of sight. I've managed to get simple comunications working over the required distance using simple transmitter and receiver sketches (provided by heltec, to demonstrate their Lora Node) sending "hello" packets

@Sasquatch said in BATERY CHARGER CONNECTION ?: Tp4056 is linear regulator, very inefficient, look at spv1040 or spv1050 instead - MPPT tracking propper solar chargers. C-x b wiki.org -> Electronics <TAB> -> Components <TAB> -> Power -> C-u M-<RET> to create new sub-heading ("MPPT tracking solar chargers"), paste (Yank) useful info for future reference. :wink:

@mfalkvidd Thx for the reply. It makes sense.

@projectMarvin said in Suggestions for my setup? Very new here.: I would advise against messing with the FW unless you need to I agree with general gist of your whole post, except this one point. If we are talking about stuff like {Tasmota, ESPurna, ESPEasy, etc.} this "messing with firmware" is how you achieve freedom / independence from "clouds" / etc. and by now has become quite mundane and easy, even being able to do so over the air, with no need of soldering. Other sorts of devices may lead to other conclusions where firmware tinkering may be much more difficult. Of course, technically you are correct by saying "unless you need to." However in my view (apparently yours as well ;) ), independence from "clouds" is a "need." Cheers!

@jo34l5, Maybe check out Dr. Zs on YouTube. His channel seems geared more to non-techies. He is big into Sonoff / Tasmota stuff, etc. which nowadays are pretty easy (you can flash them OTA, no more need of soldering). Having said that, the more you learn, the more options open up to you. Also you will pick up more and more of the stuff over time, no need to rush. Take your time and treat it as a hobby. It took me literally years to get where I am now, I finally got some certain things working that I had wanted to for a long time. But my skills (and parts inventory, etc.) was not up to par yet. Well, now it is. Another thing to consider, architecturally, is there are couple ways to tie together even otherwise disparate systems. In other words. no need to "commit" to any particular system. Here at Casa de TRS-80 we are using 433mhz, MySensors, as well as some Wi-Fi outlets, etc... There are a couple different ways to do that. Either in your controller, and/or with some intermediate messaging protocol like MQTT. MQTT is rapidly becoming something like the middle "glue" layer between disparate systems. Lots of things talk MQTT nowadays. Anyway that way you can mix and match. I bought some Wi-Fi plugs and 433mhz stuff to "get started" and get a few things working, but now I am getting better with MySensors and more "advanced" stuff... Just a thought!

I have not had any trouble just buying my radios the normal way on AliExpress. To me normal means buying about 10 or 20 at a time from the cheapest seller I can find with a high number of sales under their belt and a good reputation. I am getting nRF24 though, not sure if situation is different with RFM59W. I think most of the stuff you read in forums about fakes was from years ago. Or maybe I am just lucky.

You might want to check https://ifttt.com/instagram

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, R3 to R2, 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: Raspberry pi 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.