Reservoir water level?

[alport]

Any chance of adding another datatype: "LEVEL_T" which can be used for sending a water reservoir level?

[timmbogner]

Yep, seems reasonable. Does centimeter sound like the appropriate unit?

[timmbogner]

Okedoke you get type 25, FLUIDLVL_T LEVEL_T! Disregard the cm thing. I was thinking I defined units for the types.

It will be in the dev branch for about a week, I just need some final testing before I merge all the new features to main.

I tried to monitor my sump pit with an ultrasonic sensor this Spring, but I was bummed to find that it didn't rise and fall enough to register.

[alport]

m or cm is fine - you choose. I also tried ultrasonic, but the sensor did not like the humid atmosphere - and spiders! Briefly also tried a submersible sensor - but am now moving onto a bubbler with an external transducer - following Andreas Spiess.

Speaking of which, could you briefly motivate why you chose to define fdrs_datatypes and use a generic key "data" in the JSON string - rather than using the parameter name itself as the key?

[timmbogner]

To be sure I'm answering the right question: You're asking why it isn't like [{"id":22,"temperature":23}, {"id":22,"humidity":53}]?

The shortest answer is that I hadn't thought of it. The reason it is the way it now is because the three parameters (id, type, and data) match the C structure named DataReading used throughout the system. I can see some value in the method you describe. It would require a little more processing on the gateway end, but would make the output a bit more user-friendly. Perhaps it could be added as an option later on, let me mull it over!

[generalmanager]

Sorry for commenting on a closed issue, but I'm not sure if it's better to keep the discussion here as the usecase is identical, while the data type would be differrent.

I've got a horizontal tubular water tank, which means the water level isn't linear with regard to how full it is. One would have the same issue with a pond etc. So it'd make the most sense to me to calculate that on the sensor and then send a percentage to the gateway. You mentioned that the data types don't have units. So I guess it wouldn't even be necessary to have a new type. Though as humidity is explicity defined as a percentage, it might make sense to keep the naming scheme consistent.

[svdrummer]

Sorry for commenting on a closed issue, but I'm not sure if it's better to keep the discussion here as the usecase is identical, while the data type would be differrent.

I've got a horizontal tubular water tank, which means the water level isn't linear with regard to how full it is. One would have the same issue with a pond etc. So it'd make the most sense to me to calculate that on the sensor and then send a percentage to the gateway. You mentioned that the data types don't have units. So I guess it wouldn't even be necessary to have a new type. Though as humidity is explicity defined as a percentage, it might make sense to keep the naming scheme consistent.

I use percentage on my commercial gauges. 50% full still means something to the individual owner of that tank. In marine use, the tubular fuel tanks are laying on their side so a percentage kept the gauge as one size fits all. As the message type is a "struct" in C++(arduino) the code may not need to be changed. Arduino has a "map" function which would allow for standard formats.

[timmbogner]

Yeah I should have corrected myself here... there are no units associated with types. Their main goal is to differentiate between readings with the same ID. It is up to the user to decide on and match units for both the sensor and the front-end.

It's great to hear from new users, please stay in touch and let me know if you run into issues!

@svdrummer Also great to hear from returning users! Lots of changes have happened for FDRS since we last spoke, is your system still up and running?

[generalmanager]

Thanks for clearing this up! I like that it's unit-less as it allows a lot of flexibility and doesn't bloat the list data types. Sure will keep in touch. :)

I'm eagerly waiting for the upcoming release including ethernet and ESP-NOW LR support. :dancers: Those are two must-have features for me as I prefer to get wires as close to the edge as possible. I really like the Olimex ESP32-EVB-EA and ESP32-POE-ISO-EA boards as they allow for some additional I/O and PoE on the gateway respectively.

In my experience wifi is rather unreliable in metropolitan areas with lots of disturbance, so I want to avoid it whereever possible.

btw: Thanks for this incredible project! It's exactly what I've been looking for and saved me a TON of work to try and cobble together something similar (but certainly much uglier). :1st_place_medal:

[timmbogner]

Thanks! To be honest, this project started as an ugly ESP-NOW hack a couple years ago. It's only gotten presentable over time, and with much knowledge and assistance from the ESP/Arduino community.

Adding ESP-NOW LR mode is like, two lines of code, and I've been putting it off forever! I'll do it next. It turns out that ethernet is also surprisingly simple to add. The major holdup lately has been deciding whether to make the ethernet power pin a config inside of FDRS or out. My thought is that power pins should generally be dealt with outside of FDRS.

[generalmanager]

It takes a lot of time to form a diamond as Andreas Spiess would say ;)

Yeah I have only played around with a few different ESP-NOW examples with & without LR mode. I was just as surprised at how simple LR is as to add as I was frustrated figuring out that it's a horrible idea to use wifi and esp-now simultaneously. :') Who would've thought that i completely messes up the channels in weird and unpredictable ways and leads to a ton of dropped packages.

Regarding ethernet: I'm not sure I completely understand your thoughts on the power pin though. Do you mean an optional pin to reset/turn off the PHY chip? Could you provide an example of what you'd use the power pin for?

I havent looked into the code, but as long as you're not powering down the wifi on serial-to-wifi nodes when there hasn't been a message in some time to save energy, I don't see why you'd want to power down ethernet in the same scenario. If you however plan to implement smth like this in the future, it should probably also be defined inside fdrs.

Do you have any examples how you dealt with that in similar scenarios? You do define POWER_CTRL for sensors, but that's a pretty vital feature to tame power hungry sensors, but as it's a pretty integral feature to not drain the nodes battery too much, I don't think its very comparable.

[timmbogner]

Who would've thought that i completely messes up the channels in weird and unpredictable ways and leads to a ton of dropped packages.

Agreed! It's incredibly painful to learn on your own because things might work 90% of the time, making the other 10 feel like your own fault.

About ethernet: Yeah I sorta forgot to talk about the hardware I'll be using: ThingPulse is super-cool and sent me their newest gateway to test out, which is my first and only ethernet board. The board has the following configuration:

#define ETH_CLK_MODE    ETH_CLOCK_GPIO16_OUT
#define ETH_POWER_PIN   5
#define ETH_TYPE        ETH_PHY_LAN8720
#define ETH_ADDR        0
#define ETH_MDC_PIN     23
#define ETH_MDIO_PIN    18

ETH_POWER_PIN is just a GPIO that's brought high in setup(), so that can be done outside of FDRS just before you beginFDRS(). However, I'm assuming that I will need to make settings for the other values to be changed within FDRS config. I'll look at the Olimex ESP32-EVB-EA and ESP32-POE-ISO-EA boards and see which configs they would need.

My 4G SIM7600 board from TTGO actually uses a BMS chip that you need a library for, which stressed me out for a while until I decided not to deal with power management within the gateway (that project is still backburnered though).

[generalmanager]

Agreed! It's incredibly painful to learn on your own because things might work 90% of the time, making the other 10 feel like your own fault. True. I can't imagine how annoying beeing a tinkerer must have been before the internet when one could only dream of the plethora of free, permanently accessible information we have today.

WRT ethernet: The olimex boards (including the ESP32-EVB & ESP-POE- variants as well as ESP32-GATEWAY-*) mostly use the LAN8710A, so a very similar chip to the one in the ThingPulse, which should make it really easy to adapt.

They are also rather affordable, high quality, completely open source, well documented and many have a battery charger included. Those usually support really low deep sleep currents between 20 and 70µA.

ETH_POWER_PIN is just a GPIO that's brought high in setup(), so that can be done outside of FDRS just before you beginFDRS(). Yeah that makes sense to me. As long as it's well documented I see no issue in keeping it out of the fdrs core. :)

My 4G SIM7600 board from TTGO actually uses a BMS chip that you need a library for, which stressed me out for a while until I decided not to deal with power management within the gateway (that project is still backburnered though).

That's sometimes the best way to deal with problems: making them someone elses. ;) Jokes aside, keeping a project focused and not allowing too much bloat is a value in and of itself!

btw: should we maybe move this ethernet stuff to a new issue/discussion? I always feel bad spamming this issue with unrelated stuff.