Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOS sensor data not showing #49

Open
surfdude1009 opened this issue Jul 12, 2024 · 11 comments
Open

DOS sensor data not showing #49

surfdude1009 opened this issue Jul 12, 2024 · 11 comments

Comments

@surfdude1009
Copy link

First time here.

I have this installed and working generally but the DOS sensor data for all of my DOS' reads 0 ml all the time. The Apex is showing the amounts being dos'd historically but I can't see that data in HA. I am running 1.15 and the most current Apex sw 5.12 5O24

@brettonw
Copy link
Contributor

I am running my own fork (https://github.com/brettonw/apex-ha) with different behaviors and just updated for the DQD pumps. I don't remember the original behavior, but ...

The sensor value being returned is the remaining liquid in the reservoir attached to the pump. Have you configured that in Apex? (go to modules, select on your pump, you should see a screen like this:

Screenshot 2024-07-12 at 4 19 06 PM

Make sure you have set the total volume and the volume remaining (on the right) for your reservoir.

The actual pump speed is in the profiles, which I don't think is exposed as a sensor.

@surfdude1009
Copy link
Author

Ah, no. I was expecting that the sensor would provide the amount of fluid dos'd in the last period. Knowing how much is left in a container isnt helpful. my plan was to use HA as a way to do dynamic dosing based on various levels (e.g. low Mag, increase the amount dos'ing pump 3 is putting out by 10%).

@brettonw
Copy link
Contributor

I use it exactly that way - for instance, I monitor the salinity and run the dosing pump to control the ATO. It works out about 2.5ml/min. If you look at my fork... I created a set DOS rate service - you tell the DOS what you want, as opposed to reading back what it did.

@SolusCado
Copy link

I've found that the sensor data you're retrieving (the current status of the DOS module, it seems) only returns integers, and doesn't reflect an accurate history of the amount of solution dosed. Instead, the REST service
http://[ipaddress]/rest/dlog?days=1&sdate=[241113]&_=[1731596464823] where [241113] is the current date and the [1731596464823] is the current Unix Time (I think) will actually give you a log of DOS activity. Could we generate a sensor based on that information?

@brettonw
Copy link
Contributor

What is the source of inaccuracy?

@SolusCado
Copy link

Just the fact that it is only retrieving integer values. Dosing activity (for me at least) is often in the decimal range.

I did actually get exactly the data I needed through a combination of rest and command line sensors. I have my authentication credentials stored in my secrets.yaml, and use that against the rest/login service to get my authentication cookie. That's stored in a sensor, which is then used in a couple command line sensors that pull the rest/dlog data for both of my pumps. It would however be cool if all that could be done directly in your integration. (There are also rest/tlog (Trident) and rest/ilog (Interface?) endpoints - once you have an authentication token you can get almost all of the data that you otherwise have to get from the status.xml)

@brettonw
Copy link
Contributor

Can you say a bit about the volume you are dosing and wanting to track?

I'm not sure the fact it's an integer belies any significant error in the remaining reservoir data. Internally the Neptune only seems to use one decimal point of precision, and since the reported number is a sum of likely hundreds of doses, the amount of data loss in that little bit of rounding is less than the precision of the doser. The flaw in my argument being the assumption that your number of doses is bigger than say, 10.

If you used the Neptune app to configure your doser, the values you are retrieving are simply those set by the profile when you configured the doser (computed through for the period). Since you calibrated your device at setup, the Neptune assumes it is delivering the correct amount per dose according to the profile. It's not performing a separate measurement of how much it delivered. The remaining reservoir is a sum of all the doses it has delivered (rounded to the nearest integer).

I'm speaking out of my backside here (Neptune might have published better numbers)... The dosing pump is calibrated in whole ml (using a 40ml dose), and will have more error if you dose very small amounts - I imagine the internal precision is no better than 1/40ml (not even two decimal places), probably only accurate +/- 0.1ml - which explains the Neptune's proclivity to drop the second decimal place.

If you get all the log reports and sum them, how much difference do you note between that and the sum that comes back through the sensor? I expect the error to be bigger if the number of doses is small, but to trend towards zero as that number goes past 10. Are you dosing something that has exceptionally small amounts, like 0.1ml/day delivered once per day?

One thing to keep in mind is Home Assistant has more sophisticated analysis tools for your numbers than are available through the Neptune itself. Use the stats on the sensor to get some of the numbers you want.

My fork differs some from this one, but I have service calls for setting the dosing rate and refilling the reservoir, and I read back the remaining size of the reservoir (again the Neptune computes that based on the doses it has run at the rate you set). I use this to control my ATO based off a salinity reading, and a PID (mostly P) controller. I have line markings on the reservoir that I compare to the charts periodically, and it's close enough for my purposes. I imagine the error is slightly higher if your reservoir is small (like 1L).

BTW, I aggregate a lot of this dosing error by including most of my additional chemicals in the ATO reservoir. I assume an average dosing rate around 2ml/min (slight more during dry periods, slightly less when it's raining). But if you look at my graph, you can see a very constant trend. I fill my 30L (8 gallon) reservoir about once per week.

image

@SolusCado
Copy link

That's the crux of the matter - this part of your integration is reporting remaining reservoir capacity (which is fine - a useful metric) - but I wanted to reproduce the charts on the Apex Fusion home page that showed me recent dosing activity - so, for example "0.3ml of Reef Foundation A dosed at 9:46pm". That isn't a data point that can be extrapolated from status.xml data. That information IS however returned by the rest/dlog interface:

image

I use the data in the third column on this dashboard:

image

The top 3 widgets in that column are using data coming from the Rest service.
The next two are my remaining volumes, coming from your integration.

@brettonw
Copy link
Contributor

Oh cool! Gotcha, you want to see the actual doses. What causes your dosing rate to change, anything?

@SolusCado
Copy link

:) Hopefully, nothing! But that's why I like to keep an eye on it. Sometimes, I'll see a spike in PH, with Alkalinity on the decline, only to find that my reagent levels are low and misreporting data - so seeing the dosing data in realtime just helps confirm everything is what it should be.

@SolusCado
Copy link

OR.. there might be a voltage fault on the DOS, and if I see that there haven't been any doses at all... that's a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants