search

timmbogner / Farm-Data-Relay-System

A system that uses ESP-NOW, LoRa, and other protocols to transport sensor data in remote areas without relying on WiFi.
MIT License
507 stars 114 forks source link

One Sensor To Rule Them All #14

Closed Devilbinder closed 2 years ago

Devilbinder commented 2 years ago

The idea behind this: Change once, change everywhere.

Note: I do not have hardware to test on. Please confirm that it is working 100%. Both the 1_LoRa_Sensor and 3_ESPNOW_Gateway are in compiling state.

lekrom commented 2 years ago

@timmbogner, Great work so far. I do thinks this PR offers a big improvement though.

Interestingly, I have considered doing a similar thing. @Devilbinder, you beat me to it though. For my use-case, having configuration values set up at compile time is quite inconvenient and rather impractical. This portable class based library approach would suit me much better. Ideally, being able to set up the Unit mac, gateway mac and reading ID's at runtime would be much better and easier to deploy. Perhaps using an overloaded fdrs.begin() or separate functions for this purpose. This way, on bootup, the program can retrieve the appropriate settings from config files in SPIFFS (for example). These settings can potentially be user configured (via webserver or other UI). I think there would also be value in doing something similar with the gateways. The trick would be to not sacrifice too much of the modularity / flexibility. I was thinking of defining a gateway type based on the port type to which it transmits (LoRa, ESPNow, Serial, etc.) Perhaps one can then consider creating multiple instances of such a gateway object, where each instance listens on a predefined port. This way, one can still implement a gateway in a single physical device that can handle multiple sensor types. If this makes any sense? Perhaps there is a better way of doing this? Also, for the gateways (MQTT specifically), to have WiFi credentials hard-coded is not ideal and would be hard to deploy. I would prefer to set this up using WiFiManager or something similar. Again, having the appropriate gateway mac's configurable at run-time would make it much easier to deploy.

In any case, I would love to see how this evolves...

Regards, Lekrom

timmbogner commented 2 years ago

@Devilbinder This is awesome, thanks so much! I have been looking for code review like this for a long time! As you may have observed, I'm not really an advanced coder. I learned most of the concepts used here as I needed them to make the project work. As such, I'll need to take some time to learn about and understand your work completely before I merge and make it official. Libraries and classes are concepts that I've been wanting to learn about for a long time, and I'm very excited to have your code to use as a reference while learning. I like the modularity. A Youtube commenter gave me an idea to add UART as an output option for sensors. This would allow them to be physically connected to a gateway. I need to investigate your work a little more, but I think your new method would make that relatively straightforward, correct?

@lekrom Thanks! I definitely see your point on compile-time vs run-time. Way back in my notes I wrote "FDRS: Field Configurable" which was to be a method of using DIP switches or jumpers to configure devices. I like the idea of keeping config data in (the filesystem formerly known as) SPIFFS. The question is how to build a lightweight method of setting/changing it. Can you think of a good way to add webserver functionality without adding much battery time at startup? I've been planning a method for sensors to send special ESP-NOW broadcast packets and receive responses about nearby gateways. These packets will be set apart from DataReading packets by being smaller than them. Perhaps this could be employed to make a remote programming device that assigns config data via ESP-NOW? Serial? Maybe just a command to send it into webserver mode? I think I'm also seeing your concept with gateways. I'll be able to to discuss it a little better once I research classes and objects this week.

Thanks again to both of you! I'll be in touch!

lekrom commented 2 years ago

Glad to assist. I came across a tecnique on the 8266 where a double reset triggers a simple webserver. The device checks on bootup if the reset button was recently pressed twice. This is used on the iSpindel device ( an esp based tilting hydrometer uses to monitor beer fermentarion. https://github.com/universam1/iSpindel Could maybe do something like that. Also, it uses WiFiManager, a library that handles wifi login and credential storage for you. The library can be used to store additional config values. This is often used to store mqqt stuff and sonetimes blynk tokens for example. Should be useful here for gateway macs and the like. Could also maybe trigger "config mode" by sending a command msg.

lekrom commented 2 years ago

The WiFiManager library has some nice examples for custom setting fields. It also shows how to trigger the config portal "on demand" using a pushbutton. https://github.com/tzapu/WiFiManager

Devilbinder commented 2 years ago

@lekrom @timmbogner I am going to move the configuration to a issue as a enhancement item. My only goal is to refactor the existing code and get it tested at this point. I am going to do the same for the gateway code.

With regards to the UART. Yes it should be relatively easy just create a new class and implement that inherits FDRSBase and implement init and transmit as well as how the gatewayAddress is constructed. The FDRS_EspNow class is the best example to work off as it as the lease fluff.

timmbogner commented 2 years ago

I tried it last night and it works! The only issue I've found so far is that the UART debugging isn't working. I think the appropriate next step would be to add a temporary branch to pull the new version to while testing. Am I on the right track?

Devilbinder commented 2 years ago

Yes you are on the right track. Create a branch off main you can call it dev or whatever makes sense to you. I'll just recreate the PR into dev instead of main. Once you are happy with the PR you can then merge it into main once you are happy with it. I'll have a look at the debugging. Most repos on large projects have a branch specifically to handle new code coming in.

Devilbinder commented 2 years ago

I am going to close this PR. The new one is here https://github.com/timmbogner/Farm-Data-Relay-System/pull/17

lekrom commented 1 year ago

Sounds great..

Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Binder Tronics @.> Sent: Tuesday, June 21, 2022 7:00:57 PM To: timmbogner/Farm-Data-Relay-System @.> Cc: lekrom @.>; Mention @.> Subject: Re: [timmbogner/Farm-Data-Relay-System] One Sensor To Rule Them All (PR #14)

@lekromhttps://github.com/lekrom @timmbognerhttps://github.com/timmbogner I am going to move the configuration to a issue as a enhancement item. My only goal is to refactor the existing code and get it tested at this point. I am going to do the same for the gateway code.

With regards to the UART. Yes it should be relatively easy just create a new class and implement that inherits FDRSBase and implement init and transmit as well as how the gatewayAddress is constructed. The FDRS_EspNow class is the best example to work off as it as the lease fluff.

— Reply to this email directly, view it on GitHubhttps://github.com/timmbogner/Farm-Data-Relay-System/pull/14#issuecomment-1162018838, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE2X5IIUKWTSV7Y6BM4IOHLVQHYMTANCNFSM5ZKDF4RA. You are receiving this because you were mentioned.Message ID: @.***>