[How-To] Measure Salt Level in your Water Softener

[BraveSirRobbin]

From the Maxbotix spec:

These MaxSonar-EZ1 offers very short to long-range detection and ranging, in an incredibly small package with ultra low power consumption. The MaxSonar-EZ1 detects objects from 0-inches to 254-inches (6.45-meters) and provides sonar range information from 6-inches out to 254-inches with 1-inch resolution. Objects between 0-inches and 6-inches range as 6-inches. The interface output formats included are pulse width output, analog voltage output, and asynchronous serial digital output.

I would think it would be able to detect water or anything else that can reflect its ultrasonic signal. Might want to glance over at the Maxbotix web site listed above or even Email the vendor that question.

 

[AutomatedOutlet]

BSR,

The pool must maintain a low salt level for the ionizer. I don't use clorine at all. I'll have to look up what the levels of salt are but it's not that much. In a 25,000 Gal pool, it works out to about 300 pounds of salt or so.

 

[Steve]

BSR,

The pool must maintain a low salt level for the ionizer. I don't use clorine at all. I'll have to look up what the levels of salt are but it's not that much. In a 25,000 Gal pool, it works out to about 300 pounds of salt or so.

I use the AutoPilot which also uses salt to create pure chlorine, but there is no physical storage of the salt to sense. You have to measure the dissolved concentration and add a 50 or 100lb bag occasionally.

OTOH, I have a complete water treatment system. The softener components are outside. It uses a separate salt storage tank. I'd like to do something like this but I would have to:

1. Find a way to get a wire outside on that pad
2. Attach it to the container in such a way is to be waterproof and easily removable

Needs to be removable because I take and clean/bleach the holding tank every few months. While its cool, it may just be more work than its worth in my situation.

 

[AutomatedOutlet]

I use the AutoPilot which also uses salt to create pure chlorine, but there is no physical storage of the salt to sense.

Steve, I don't have physical storage of salt either. The system just needs a certain number of PPM of salt for the ionizer to work properly. Salt only needs to be added if you lose some from backwashing or water splashing out.

 

[Bruce L]

I need to use several of these tied to the same microcontroller. I'm measuring water level in several (3+) tanks. Can I tie all the TX lines from the sonar together or will that damage the drivers? If all the TX lines are together then it really simplifies the rs232 receive on the MCU. I will use the RX lines to select only one sonar to transmit at a time to prevent collisions on the TX line.

If I can't tie them together then I'm thinking of using a multi-input AND gate as I believe the RS232 line idle is high - right?

 

[FrankMc]

Hi Bruce

I started on a pic micro based system to control the maxbotic and what i have done is to connect both the mabotic and pic tx lines via a cmos 4066 switch..By default the pic has the tx line and i use a timer in the pic to switch over the tx line and at the same time enable the maxbotic......So you could do the same with another 2 maxbotics as there are 4 switches on the 4066....

HTH
Frank

 

[FrankMc]

Hi Guys

For those interested Gerry Duprey is currently working on a project which will allow up to 12 Maxbotic devices to be connected to a microcontroller..Below is an email i recieved from Gerry regarding his developement so far.....any feedback welcomed..

Thanks
Frank

*********************************************************************

Once I get that working and write a quick parser for received reports, what is
left is:

1) Logic to continually poll each device (poll each one for a few samples).
2) Logic to update internal values for each device and trigger reports when
a value changes (if change reporting is enabled for that device).

I don't think either will be that hard. That will provide

1) Ability to monitor 12 devices
2) Keeps the polling/scanning/comparing/constant reading isolated to
the PIC

I think that gives the ability to have each sensor independently configured as

1) Polled. Never sends an unsolicited report, only responds when queried
2) Triggered. Sends a report anytime there is a change greater than a defined
threshold (default threshold: 1). Can still be queried like a Polled
sensor at any time
3) Periodic. Sends a report every X seconds regardless of whether there is a
change or not. Can still be queried like a Polled sensor at any time

I can't think of any other ways that I'd want to track a sensor.

Using a 16F88/87, I'm seeing:

RA0-3, RA5-7, RB1, RB3-4, RB6-7 as sensor select lines that are held
high until it's time for the sensor to report.

RA4 is an input only, so we can leave it as MCLR (since it's not of much other
value) or just ignore it. Or we could use it as a single bit baud rate
selector (low = 9600, high = 19200 or 38400?).

RB0 is where all the sensors feed their serial stream into (use steering
diodes and a single pull-up resistor so they don't drag each other down -- it
appears that even when disabled (RX low), they put out +5 on the TX line

RB2 is serial in (RX) to the UART
RB5 is serial out (TX) from the UART
RB2/5 go to a MAX232 and then the computer.


For a protocol (serial), my initial thinking was

$CCSS...
CC is a command/report code, SS is the sensor # and ... is any parameters.


Commands:
---------
$10SSFFPP
Configure sensor SS (00-0C) with flags FF and parameter PP

Bit
0-3 - Reporting Mode
0000 - Polled.
0001 - Triggered
0010 - Periodic
1111 - Disabled (not checked/tracked)
(other values reserved)
4-7 - Reserved

If Periodic, then PP is # of seconds between reports.
If Triggered, then PP is # of units change before a report is sent
For other configurations, PP is ignored

All sensors initially are defined as disabled. Sensor configuration
is stored in EEPROM so it only has to be set once.

$20SS
Query Sensor SS for it's current value. Causes a $80 value report
to be sent.

$21SS
Query sensor SS for it's configuration. Causes a $81 report.

Reports
-------
$80SSVV
Result of a $20 Query, returns the current value, VV for sensor SS

NOTE: Disabled sensors will report 00 if queried

$81SSFFPP
Current configuration for sensor SS with FF and PP having the same
definition as they have in the $10 command.

$90SSVV
Triggered report, result of a change in a sensors value (for triggered
sensors) or periodic time (for Periodic sensors). SS is the sensor,
VV is the value.

Note: I generally have my reports use the top nibble to indicate the
reason for the report and the lower nibble to define the report itself. That
means all $8x and $9x reports will have the same parameters and meaning for a
given value of "x", so a parser that doesn't care why it got the report can
just look at the low nibble to determine what report it is. If a parser does
care about a status vs triggered report, they can check the top nibble. Not
all reports have a corresponding trigger version and vice versa.


$F0
Sent to confirm last command was received, valid and completed. Note
that for some commands, the command may generate responses before
the command completes. So you may receive reports or triggers after
a command is sent but before the $F0 or $F1 is returned.

$F1
Sent to indicate the last command was invalid or encountered an
error while executing (i.e. bad command code, invalid sensor #,
invalid configuration command, etc).

This is substantially similar enough to my sprinkler protocol that I can adapt
my sprinkler xPL gateway with only 1-2 hours work to it. The nice thing with
the $F0/1 response codes is that it creates an automatic command pacing --
send a command, wait for a response (with some large timeout value -- I
usually use about 10 seconds) so you don't have to worry about delays (like
you do with the RGBLED controller).

Like I said, the 60% I have done is really copy/paste job, but the rest of it
should be pretty easy (except the software serial IN -- that is a bit trickier
due to timing, but I have little doubt it can be done. So pursuing this (the
PIC code) or not is not a huge "cost" for me either way.

Thoughts?

 

[smee]

I think it would be valuable to add an additional mode.

Have 2 threshold values for the sensor: threshold-low, threshold-high.

Whenever the distance is less than threshold-low, trigger a message. Wait until the distance is greater than threshold-high, then trigger another message. It basically toggles between two states - in range and out of range. Having two threshold values prevents it from oscillating back and forth when an object is on the boundary.

This could be configured as a simple motion detector or a sensor to determine if an object is present/absent. Obviously, this logic can be built into whatever is receiving the output of the device but building it in will simplify some configurations (and remove the need for additional programming by people who may not be as sure about how to code it).

 

[BraveSirRobbin]

I agree with smee. This device would be great to use as an outdoor motion detector as it is immune to all of the "heat detection" problems of common detectors.

The problem is if the computer is monitoring it in "free run" mode, to much CPU time is consumed. There really isn't a good way to "poll" the device either in most motion detector applications.

So if the device could just free run and let the HA computer know when a threshold has been reached, that would be ideal.

Also, think big. These things could be used as parking indicators for when you pull into your garage door, vehicle indicators, etc...

Also, as mentioned before, it would be nice to "poll" the serial port and ask for the status of the sensors. It would be nice to keep the serial protocol simple so it can easily be adapted into programs such as Homeseer. Say, if any character was sent to the serial port all sensors would report back their current status in one string (maybe separated with a character for each sensor)??

Just something so it's easy to concatenate the string.

Sounds like an exciting project with a lot of potential!

 

[FrankMc]

Hi Guys


Hopefully Gerry will correct me if im wrong...

Gerry intends to read each sensor into the pic and then when required send the info down via the pic micro,s tx line to the pc ....So the Devices wont be Free running and eating up cpu time.....

Threshold Low , Threshold High , these would come under the
(2) "Triggered Event" that Gerry has mentioned ........

As far as reporting all Sensor values in one message , im sure its doable , but if you only have a couple connected it would still have to report 00 for each sensor thats not connected..... I have a report ALL probes command in my Probe system but to be honest i never have used it as i only have 3 probes max on each zone currently....
I suppose having a report all command would be handy when a lot of Sensors are installed.....Looking forward to Gerrys comments on this........


Frank

 

[smee]

Threshold Low , Threshold High , these would come under the
(2) "Triggered Event" that Gerry has mentioned ........

I don't think so - or at least not the way I read his description. "2) Triggered" sounds like, for example, every time the distance changes by more than 4 inches, send a message. What I'm describing is, again for example, send a message whenever something gets within 48 inches of the sensor. Then, send another message whenever there is nothing within 60 inches of the sensor. So, if something moves near the sensor a message will be sent. But, it will not continuously send messages. A message will be sent again when the object moves beyond 60 inches. By using high and low values here, you can avoid many messages when the object moving back and forth right around 48 inches.

As far as reporting all Sensor values in one message , im sure its doable , but if you only have a couple connected it would still have to report 00 for each sensor thats not connected..... I have a report ALL probes command in my Probe system but to be honest i never have used it as i only have 3 probes max on each zone currently....
I suppose having a report all command would be handy when a lot of Sensors are installed.....Looking forward to Gerrys comments on this........

I think this is valuable even when you only have a few sensors. If you are using interrupt driven communications on the PC end of things (such as having HomeSeer trigger whenever a certain string comes in to the serial port), it can be easier to just have this event triggered once and parse the data there. Otherwise, you will have to send multiple commands to query multiple sensors and handle multiple interrupts.

As far as the message protocol goes, are the reports sent from the device to the PC binary (bytes) or ASCII? I.e., in the report "$80SSVV" is it sending the characters "8" and "0" or is it sending the byte value 80? I guess I'm not sure if the "$" is a literal part of the message or if it's indicating that the rest of the stuff is in hex.

If the messages are not being sent as human-readable characters, then I'd suggest considering changing it so that they are. This makes it easier to debug - you can use hyperterminal - and often easier to handle programmatically.

If they are being sent as human-readable, I'd also suggest adding a terminating character - at least to the messages being sent from the device to the PC. A carriage return or line feed, for example, which would not occur in the normal message can greatly simplify handling messages on the PC side. In HomeSeer, for example, you can set up an event to trigger when a particular character is received. The entire message is then available for parsing. This saves you from needing to run an event every time a character is received and checking to see if you've received the complete message yet.

 

[BraveSirRobbin]

Again I greatly agree with Smee!

If the protocol of the serial port is not something simple that can be used with "hs.opencomport" type statements, it's not going to be of much use to this community!

For an example of a serial port's integration into HomeSeer for example take a look at THIS thread.

That PHAnderson analog to digital converter is a simple ascii string with a CR/LR at the end. Transmission is initiated with any character sent to the serial port.

If this is done in this case HomeSeer users for instance can just create HomeSeer devices (house and unit code virtual devices) in their setup and have the values of each sensor "stuffed" into those devices. Now this information can easily be used for other HA applications.

Maybe Smee and Gerry can chat sometime via phone? Smee is the expert here when it comes to these things and it would be nice to have Gerry's product useable for the HA community.

 

[gduprey]

Howdy,

Couple of notes to address some of the posts:

1) The protocol is text based. The $ is literal and is an "intro character" and all commands to the PIC and reports back from teh PIC start with it and end with a CR (ASCII 13). The values are Hex characters, so the strings are always multiples of 2 characters, each 2 hex characters making a "byte".

2) You can control or request info for either a specific sensor or for all sensors. Just replace the sensor (SS) with FF (wildcard) and a report will be sent out with the value for each sensor So a $20FF command will result in all sensors being reported back (i.e. a $80SSVV report being sent for each enabled sensor).

3) The main point of the PIC is to take the "load" of watching the sensor off the PC or whatever it's attached to and to allow multiple sensors to be connected to a single serial port. As such, unless things in front of a sensor are wildly changing, the actual traffic across the serial link to the PC will be very low even if the sensors are sending an unending stream of data to the PIC.

4) On the suggestion to have a high and low limit, I'm a little relunctant to do that. The existing triggers allow you to impose whatever higher level interpretation on the sensors you want without much work (as you'll get updates, if enabled, whenever things change) at the PC. I'd prefer to keep the PIC functions minimal and basic..

Hope that helps,

Gerry

 

[BraveSirRobbin]

Hi Gerry;

We posted at exactly the same time (just wanted to make sure you saw my reply above yours).

Thanks,

BSR

 

[gduprey]

No fear about the HA community -- that's what I target for.

You can check out the HA sprinkler controller as an example -- it uses a conceptually similar protocol format. Or the RGBLED stuff.

Everything I build (software or hardware) is all geared to HA use and integration into HA systems. In fact, that is why I've gotten so heavily into xPL -- I was sick of having to write "one off" protocol converters for every new piece of software and hardware out there.

If all devices supports xPL, then things like HomeSeer, CQC, MisterHouse, etc could all use the same interface protocol and share in control of devices.

So anytime I create a new HA related software or hardware product, my approach is to start with a simple protocol/interface spec that can be tied into the widest variety of control mechanisms out there. Then I always provide an optional xPL gateway layer/module that runs on a computer so that if you don't need low-level connection, you can gateway the software/hardware onto the xPL network and control it via any xPL enabled tool.

I know most of you folks don't have much background on me as I'm pretty new to this forum. I have been lurking around other HA places for years, but often in more niche areas. Hopefully, I'll be able to contribute to the community here soon.

Gerry

P.S. If anyone is interested, you can read up on my hardware projects at the rgbled site, my xPL work at the xpl4java site and about the implementation in my home of HA at the cdp1802.org site in my signature.