@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.

I am sorry but your reply is still not very helpful. In general I feel like this is an interrogation session in order to discover relevant information, making the whole process much more difficult than necessary. Please keep in mind that we know absolutely nothing about your system other than what you tell us, and if we instead substitute assumptions, that can lead us to wrong conclusions. In other words, please be more forthcoming with relevant information so we don't have to keep playing this cat and mouse game. :) @amkochaki said in V_VOLTGEM EXAMPLE: My motion sensores are the same of my alarm system. I don't think that you mentioned anything about what is your alarm system, how it works, etc. therefore this statement is meaningless (at least to me). Perhaps I missed something? @amkochaki said in V_VOLTGEM EXAMPLE: Are connected on analogic pins. Perhaps you are unaware, but the analog pins on the arduino can also be used as Genral Purpose Input Output (GPIO) pins, aka digital. So again, this statement still does not clarify whether your sensors are analog or digital... @amkochaki said in V_VOLTGEM EXAMPLE: So I need that Arduíno read voltage of the sensores. Yes, of course. But (at least to me) we still have not determined whether they are analog or digital... Both are measuring voltages, the question is how... Perhaps you are unfamiliar with difference between analog and digital? I don't like to assume anyone's knowledge level, which can lead to wrong conclusions. On the other hand, I don't want to insult anyone, either... ;)

Wow, I would have never thought that many either! Well done, guys. :clap: 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.

@mrussi Not sure if you still need this info, but I'll leave it here in case anyone else needs it. I couldn't find this either so i had to look at the heltec pinout diagram and compared to the ESP32 Library /* * The MySensors Arduino library handles the wireless radio link and protocol * between your home built sensors/actuators and HA controller of choice. * The sensors forms a self healing radio network with optional repeaters. Each * repeater and gateway builds a routing tables in EEPROM which keeps track of the * network topology allowing messages to be routed to nodes. * * Created by Henrik Ekblad <henrik.ekblad@mysensors.org> * Copyright (C) 2013-2018 Sensnology AB * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors * * Documentation: http://www.mysensors.org * Support Forum: http://forum.mysensors.org * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * ******************************* * * REVISION HISTORY * Version 1.0 - tekka * * DESCRIPTION * The ESP32 gateway sends data received from sensors to the WiFi link. * The gateway also accepts input on ethernet interface, which is then sent out to the radio network. * * Make sure to fill in your ssid and WiFi password below. */ // 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_DEBUG_VERBOSE_RFM95 #define MY_RFM95_RST_PIN 14 #define MY_RFM95_CS_PIN 18 #define MY_RFM95_IRQ_PIN 26 #define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN #define MY_SOFT_SPI_MOSI_PIN 27 #define MY_SOFT_SPI_SCK_PIN 5 #define MY_RFM95_FREQUENCY (RFM95_868MHZ) #define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF128 #define MY_GATEWAY_ESP32 #define MY_WIFI_SSID "WiFi_SSID" #define MY_WIFI_PASSWORD "password" // Set the hostname for the WiFi Client. This is the hostname // it will pass to the DHCP server if not static. #define MY_HOSTNAME "ESP32_GW_LoRa" // Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP) //#define MY_IP_ADDRESS 192,168,1,100 // If using static ip you can define Gateway and Subnet address as well //#define MY_IP_GATEWAY_ADDRESS 192,168,1,1 //#define MY_IP_SUBNET_ADDRESS 255,255,255,0 // The port to keep open on node server mode #define MY_PORT 5003 // How many clients should be able to connect to this gateway (default 1) #define MY_GATEWAY_MAX_CLIENTS 2 #include <MySensors.h> void setup() { // Setup locally attached sensors } void presentation() { // Present locally attached sensors here } void loop() { // Send locally attached sensors data here }