Seeed i2c water level sensor

[treii28]

How could i go about using this with EspEasy? Do I have to hack together a new plugin and compile my own binary or is there a 'generic' or other type of plugin that might work with it?

https://wiki.seeedstudio.com/Grove-Water-Level-Sensor/

It uses two ic2 addresses and near as I can tell by reading (I haven't gotten it yet from Seeed) it returns a comma separated list of values from multiple capacitive sensor points at various increments on a pc board.

[Ath]

That sensor is using a rather weird technique of 2 I2c addresses to read different parts of the data. Haven't seen that before, this sensor isn't yet supported by ESPEasy.

For developing an ESPEasy plugin, there's sort of a standard procedure:
- Request a new plugin ID at https://github.com/letscontrolit/ESPEasy/issues/3839
- Develop the plugin using this ESPEasy development guide: https://espeasy.readthedocs.io/en/lates ... ormIO.html

If you don't have the skills to develop a plugin, we can do that for you, but we can't give an ETA (unless you want to make it a paid assignment )
For testing the plugin, you could probably do that, if you own such sensor.

[treii28]

Yeah, I've been looking over both of those and posted a request just before coming back to this thread to look for responses on the first. I'm not really a C/compiled languages programmer though, even though i did do some object-based coding in CLion for a power-relay box based on an ESP8266 a few years back.

In this instance I'm looking for a quick-and-dirty way to set up a monitor for a new hydroponics rig I set up out back by the garden. It looks like ESPEasy can handle switching a relay on and off, read the current used and voltage levels via i2c sensors, but I would love to be able to monitor the water level in the reservoir. It looks like the supported sensors for that would only tell me binary information (high enough or too low) which is better than nothing, but knowing the precise level of the water would be interesting to monitor. (when the pump is on, the level goes down about an inch as extra water is circulating through the PVC pipes)

I'll poke at it with a stick some more, but I really feel like the apes at the start of 2001 prodding the obelisk when dealing with an existing C codebase like ESPEasy. I can hurl rocks and bones at it, but won't get much further than that. (give me intepretive languages on the other hand.... well that is except python. I still can't comprehend why people code in that language. It continually gives me nothing but grief! If your language needs an isolated virtual environment to even hope to function without corrupting your OS with incompatible dependency requirements, chances are you need a better language platform! and don't even get me started on the 'spaces' mattering...)

[Ath]

I've reserved P170 for this plugin, and put it on my name
I'll need you for testing once I've done some coding.

[treii28]

Well, I may give it a hearty try, but 'try' for me on this sort of thing will amount to looking for examples into which to cut/paste code. I don't necessarily have a problem writing code for embedded devices, I'm just not good at figuring out the requirements of existing codebase/platforms/suites in C such as ESPEasy. So i can definitely help test and once I see an already built chunk of code, i can probably even provide suggestions. But getting from zero knowledge of C-integrations and zero knowledge of ESPEasy framework to a plugin, probably not going to happen (unless I find a really good/simple starting point)

(I also find the existing documentation both for ESPEasy as a user tool and for development to be seriously lacking. This isn't so much a condemnation on ESPEasy as most documentation these days is seriously lacking. People who write code seldom know how to write comprehensive instructions)

[TD-er]

Can you give some concrete examples of what you're missing?
Also it is really really hard to write documentation for devs to start developing on some platform as you don't know what level of experience someone has.
If you try things too verbose, people won't read it.
If you turn the verbosity a bit down, people don't understand what to do.

One example of me working at a computer store helpdesk with someone on the phone (end-90's era) trying to tell someone to switch to the floppy drive: "Type A:" ("colon" in Dutch is called "double point")
Then you hear on the phone <click>...<click-click>

So what level of experience can you expect? This person really didn't know what a colon was and how to type it on a computer.

The same for a programming environment like ESPEasy.
We do have tutorials on how to setup a build env.
We do have example files (some might be a bit dated) and you can still look for some plugin which is somewhat similar and try to make it work.
As soon as you try to make a pull-request to get it merged, you will for sure get lots and lots of hints, tips and requests to change some code.

Some only ever programmed in the '80s in BASIC, while others have like decades of professional coding experience in C/C++ and can also teach me and Ton quite a bit on coding.
It is really hard to find a good middle ground on what should be explained and what not.

So if you can give some concrete examples on what is truly missing, please tell us.

[treii28]

re: don't know what level to write

That is kind of what I'm referring too. You get one of the two extremes. Written as though you're already very experienced or way too wordy providing way too much information.

When I retire in about 10 years, I plan on trying to write fiction (mostly sci fi) for extra cash-on-the-side. But if I wind up needing money, doing technical writing may be an alternative. There are ways to write thorough without being overly wordy. But it seems to be a lost art. My father was a school teacher, and even he made some extra side 'perks' in his retirement writing reviews and instructions for companies with products he often used. (in exchange for free samples and 'product testing' privileges. His photos were prominent on Stealth trailcam website for years and i think they are still using some of his suggestions in their instructions, for example)

It's hard to just describe beyond generalities as it would kind of be like summing up to me how to program for your platform in a single post. The important thing is that it needs to have 'enough' relevant information for both without winding up being too wordy or being overly brief. My personal preference for programming instructions are sufficiently comprehensive examples. i.e. examples that cover most common contingencies for any given scenario, library, plugin, component, widget, etc. And then include links to 'get more information' for more detailed and obscure edge-cases, even if that's just a pointer to an appropriate forum to ask.

I also like skeletons. I just finally found your 'PluginTemplate' and I'll take a look at that further tonight. It looks like there are a lot of good comments in there, it will just depend on whether or not I can get my brain wrapped around the differences between the C++ and the interpretive code styles I'm more familiar with.

This particular i2c device is probably not a good starting point though as it seems to put an ATTiny between the i2c 'output' and the actual sensors, splitting multiple sensor data results into two i2c addresses that puke up comma delimited lists. I doubt you have any examples in the code base that will resemble what this thing is doing. I'd imagine the data coming back is probably a (null terminated?) char-array as far as C is concerned. or at least a fixed length array. I haven't dived into the example ino that far either.

[TD-er]

Yep, that's indeed what I meant.
But also about ESPEasy specifics.
I do have some block diagrams to explain concepts and naming schemas, but is this sufficient for someone who isn't used to think in logical blocks?
Ton also made some tutorials on how to start implementing some functionality.
But can someone that really needs this find it?
I even have to search for a while to find some example as I can't come up with the exact keywords to search for in the docs.

[treii28]

yeah taking a quick peek, it looks like one address returns 12 bytes of data, the other 8 bytes. Their example uses the Wire library.

[treii28]

OK, found a great concrete example. There's a page on the BME280. It includes a link, as does the espeasy interface to the formulas page. There's a formula for converting celsius to fahrenheit. The example shows using a static value like 86.
There's also a comment in the 'rules' page on a task named 'bme' with a value 'H' when using the temperature formula with an example.

I still have absolutely no clue from all three of those places what exactly I am supposed to be putting in the temperature formula field to convert the plugin's value to fahrenheit.

OK, after some digging around, I learned 'event' refers to an instance of a controller (a defined device) so I'm assuming it's some variation of bme%temperature. One page says plugins/events can have up to 4 named values. Is the name something internal or is it what's filled in under the name fields? And is the event bme or is it whatever I named the device at the top? (I'm going to have two INA219 devices hooked up to this, for example)

I see a field to 'force speed to slow' but have yet to find a definitive explanation of when this is necessary or how you go about finding out.
I see there's checkboxes to pull all three values as a single event. Um, ok, where does it say when and why this might be preferred?

I'm assuming in this section: https://espeasy.readthedocs.io/en/lates ... lue-events the referenced to 'event called' means 'an event with a name set to'. If there's a field on the form that says simply 'Name', consider changing the label to 'Device Name' then use the word 'Device Name' in the documentation to make it more obvious exactly what you are talking about. Saying 'called' doesn't let you know in what way it is 'called'. Called in the plugin defined name? The user defined name? Something else entirely?

It's also a good idea when a designator for a given thing isn't entirely obvious such as 'event' defining an 'instance of a device' that is based on a 'plugin', put a hotlink under the word 'event' anytime it is used to refer to that specific thing or at minimum, put a mouse-over pop-up description and highlight the word in some way so it is obvious it's not just a reference to some ambiguous event occurring but it is actually a 'defined term' relevant to the device or something else described in the documentation.

Someone unfamiliar with what your code base does isn't going to know where to begin with such a large set of documentation. They might not need to read up on a BME280 or even a 'plugin' or 'device' definition if they aren't going to be using those in their setup. They may jump straight to 'configure' or 'rules' and won't know what have the things on the page refer to or even what words in the context of the instructions refer to terms relating to distinct facets of the espeasy-specific terms.

[treii28]

Short version:

When writing any technical documentation, assume your reader is either a clueless noob idiot, or a very busy genius. (as most brilliant types are always busy, or at least assume they are -- and in the context of a technical document, they both mount to the same thing anyway)

[TD-er]

In the formula field, you refer to only local 'stuff'.
So essentially %value% for the raw value as what should have been put on the output of a taskvalue.

For this specific conversion from Celsius to Fahrenheit, there is a conversion ready which can also be seen on the sysvars (tools->System Variables) page of the web interface. (bottom of the page)


For your specific question, the formula field can be done like this:

Code: Select all

%c_c2f%(%value%)

[TD-er]

About 'event' handling.
Only when you have the rules enabled (tools->Advanced page almost at the top), events are generated.
These typically have a form like this:

Code: Select all

myeventname=123.4,56.7,8,90

Where "myeventname" dan also contain a '#' to separate things like "taskname#taskvaluename"
The values right of the '=' are called eventvalues.

In a rules block you act on an event.
In such a block you can refer to these eventvalues using %eventvalue1% ... %eventvalueN%

Here you see the difference in 'scope' between event handling and formula fields.
The local values for an event are %eventvalue1% ... %eventvalueN% and for a formula it is %value%.

To refer to other taskvalues, you can use the [taskname#taskvaluename] notation (square brackets).
For example if you have task called "bme" and taskvalue "T", you can refer to this value using [bme#T]
N.B. this is the value after processing any formula.

So let's assume you have checked the checkbox in the task to combine all taskvalues as a single event and the taskvalues for the BME280 are in this order: T, H, P
Then you can compute the dew point like this (in rules):

Code: Select all

on bme do
  // order eventvalues: T, H, P
  LogEntry,"Temp: %c_c2f%(%eventvalue1%){D}F, Humidity: %eventvalue2% % DewPoint: %c_c2f%(%c_dew_th%(%eventvalue1%,%eventvalue2%)){D}F"
endon

Would this be more like how the documentation should be?

[treii28]

I eventually figured out the magic word was %value% after multiple attempts and guessing.

[Ath]

@treii28 I've created Pull request #5056 to add support for the Seeed studio I2C Liquid Level sensor.

Assuming you either own or have ordered such sensor, can you please test, using a build from this GH Actions run?
You can report your findings & remarks here or in the PR.

[treii28]

I'm still waiting for the component to show up from Seeed, but I'll give it a shot as soon as it arrives. I'm fighting with the other sensors at the moment. (the INA219 doesn't seem to want to read current and the BME240 apparently doesn't support humidity. The two I ordered to replace it wouldn't work at all. This is why I hate hardware! Give me stuff that is known to be working and I can program circles around it, give me component parts and I get nothing but frustrations)

[treii28]

can you please test, using a build from this GH Actions run?

OK, in preparation for when it shows up, I have a feeling I'm going to need a little more info to know how to build something off of that. (not a C person and I have a love-hate relationship with git)

EDIT:
I think I got part way there, reading around da internutz.

Code: Select all

~/src/ESPEasy$ git fetch origin pull/5056/head:pr5056
~/src/ESPEasy$ git checkout pr5056

I wasn't sure at that point if that was where i was supposed to build so I did a platormio run and tried uploading the resulting image but didn't see P170 in the device list.

I then did:

Code: Select all

$ git fetch origin_mega origin/mega
$ git checkout origin_mega
$ git merge pr5056
$ platformio run

But again don't see P170.

So what am I missing?

[Ath]

can you please test, using a build from this GH Actions run?

OK, in preparation for when it shows up, I have a feeling I'm going to need a little more info to know how to build something off of that. (not a C person and I have a love-hate relationship with git)

...

But again don't see P170.

So what am I missing?

That link I shared leads to the GH Actions run that, when you're logged in with a Github account, allows to download complete binaries for any build you want. For your ESP32S3 with 8MB Flash you can download one of these 2 zip files by clicking the name (probably the one with OPI_PSRAM in the name, as your board has PSRAM),

Screenshot - 20-05-2024 , 19_15_42.png (7.04 KiB) Viewed 578 times

(Direct link)

The zip file contains 2 .bin files, and the one with the .factory.bin extension can be loaded onto a new (non-ESPEasy) ESP32S3 at address 0 using the Espressif Flash Download Tools, that can be downloaded here. (Windows only...)

Screenshot - 20-05-2024 , 19_26_56.png (73 KiB) Viewed 578 times

Once that's done you can reset the ESP (it's probably already reset by the Flash Download Tools), so you can set it up further.

[treii28]

I tried uploading the one you sent, the device stopped responding. (I'm at work, device is at home)

SW

[Ath]

... (the INA219 doesn't seem to want to read current and the BME240 apparently doesn't support humidity. The two I ordered to replace it wouldn't work at all. ...

Both the INA219 and BME280/BMP280 (and a lot of other sensors too) are often 'unclearly labeled' by many of the low-cost suppliers (Aliexpress, eBay, etc.), with the net result of either not working as expected (cheap nock-off INA219) or BME280s turning out the be BMP280 that don't have the Humidity sensor. Edit: The Device configuration will show what's detected when the task is enabled.
Most suppliers will refund on a filed complaint, as the return postage is more expensive than the refund.

[Ath]

I tried uploading the one you sent, the device stopped responding. (I'm at work, device is at home)

SW

What exact bin file did you upload previously? (don't see it mentioned in this thread)

[treii28]

The one I tried compiling. Both cases it came back up but I didn't see the 170 in the list of devices when I tried to add a new device.

From the zip file downloaded, I tried uploading the *.factory.bin

[Ath]

From the zip file downloaded, I tried uploading the *.factory.bin

If you upload that via the Web UI, the unit will go into an endless boot-loop...

When updating via the Web UI (Tools/Firmware update) you should update only the 'sketch', the .bin file, that's installed at the 'other' app partition (determined by the uploader in the firmware), so it can survive a failed upload.
The .factory.bin file also includes the bootloader and partitioning data, and should be uploaded via an external tool at address 0.

[treii28]

uh, ok, confused. Because from the ones I compiled I was uploading .factory.bin as well and it was reloading.

[Ath]

The one I tried compiling. Both cases it came back up but I didn't see the 170 in the list of devices when I tried to add a new device.

I don't think you pulled the PR to your local system with the commands you listed, the PR is in the pull/5056 pseudo-branch on GH.

My workflow for building someone else's PR locally is like this:

Code: Select all

git clone https://github.com/letscontrolit/ESPEasy
cd ESPEasy
git checkout -b pulls/5056 # I collect my PR branches in pulls
git fetch origin pull/5056/head
git pull origin pull/5056/head

(The # comment is not part of the command...)
After these commands I can locally build the PR, often adding test-modifications , without 'polluting' my clone with all kinds of PR code, as I can return to the mega branch and start all over, if needed.
When the PR gets updated, I repeat the last 2 commands to update my branch.

Edit: Changed upstream to origin, I added the upstream remote a long time ago...
Edit2: Fixed a typo in git checkout...

uh, ok, confused. Because from the ones I compiled I was uploading .factory.bin as well and it was reloading.

What was the exact build that was built and uploaded?

[treii28]

I ran home on lunch, manually uploaded the bin and still no P170

[treii28]

Following those revised instructions, I did another platformio run and uploaded the resulting .bin and I can now see the option. I also checked and the shipment from Seeed apparently rounded the corner in Jersey City. So I should be set to try it out in a few days.

On an aside, unplugging the xiao S3 and bringing it in the house to program it, I apparently did something to bonk the I2C as I'm not seeing anything on the bus now. Ugh, I hate EE

[treii28]

Just curious, why 'Input' and not 'Environment'?

[Ath]

Just curious, why 'Input' and not 'Environment'?

Mostly for lack of a better category. Environment implies it has something to do with our living environment, like temperature, humidity etc. and a water level doesn't do that, IMHO. It is an input-only sensor though...

[TD-er]

Hmm that's indeed a tricky one, which is a suitable category.
Quite a lot of setups use ultrasonic distance sensor to measure water levels, so this could also have been "distance", which might even be more confusing when searching for this plugin

[treii28]

The housemate says they asked her to sign for a package today and she shot me a picture. For some reason the description read 'classroom training supplies' but using google lens on her photo i can see next to it in Chinese reads 'water level sensor'. So I should be able give it a test later tonight if I can get all my wiring issues worked out.

(this morning I couldn't get the 12v->5v 'hot' side wire to connect to the battery so I finally just pulled the wire out and connected it straight to the battery pole. Then the plug for the pump was acting erratic so I ended up yanking it out just so the plants can get water today. Looks like plugs outside in the dew won't do! I could see where it was rusting up despite the chroming on it. So I'll go with shielded inline plugs and likely slide some heat shrink over it. Did I mention I hate EE?)

[treii28]

Ooooo nice implementation and it seems to work like a champ. I grabbed a lemonade and proceeded to slide up and down in it and it was reading out accurately.

[Ath]

Great

I've also ordered a sensor, and expect to get it delivered today or tomorrow, so I'll play with it soon

[treii28]

You mean you ordered your own 'educational training supplies'?

[TD-er]

Lab equipment.