Add support for IntelliValve

[theRealMCQwerty]

Continuation of closed issue https://github.com/tagyoureit/nodejs-poolController/issues/116

The IntelliCenter is supported but the IntelliValve is not. Or at least not supported via RS485 for incremental control of the valve actuator position.

@rstrouse has made some good progress but with the previous issue being closed there is nowhere to continue the discussion on this particular issue.

@rstrouse - do you have an update on current state? Is there anything I can do to help?

[thumbnut]

Did that - no apparent change in the message window. Still cycling through the same numbers at the same speed. Roughly 10 per second.

[rstrouse]

Btw it is normal to have failed messages. This is just because we are pumping so many messages on the bus. What I don't like are the numbers in red that indicate we are waiting to send. I will add some code to only send when the send buffer is empty.

[thumbnut]

It looks to me like the position of the red 82 and the green 126 are changing at the same rate. Should we not go through a complete sequence of the 4 and 126 before advancing 82 to 83?

[rstrouse]

@thumbnut the red byte is the action byte and it should be incrementing to 255 at which time it will flip the 16 which is the destination address to 17 then start over again at 0 once that switches to 255 it will flip 17 to 18 then start the action at 0 again. The byte in green is actually the checksum so it is calculated for the message. If there are two bytes that I am absolutely sure about that is your blue and green byte. The readme outlines how this is calculated.

What this is doing is trying to find the correct action byte and destination address to rattle the valve. So far it looks like action 80 wakes it up on a destination of 12 or 15. These addresses are a bit odd to say the least since a destination of 12 is hail and 15 is typically a controller. It is responding to 16 broadcast which is expected.

[thumbnut]

OK thanks for the explanation. Still chuggin' away.

Since changing the delay to 200:

[thumbnut]

One thing I never asked was the polarity of the green and yellow wire on the dongle. I have green on Data- and yellow on Data+. Is this correct? I am going by the only reference I saw for the intellicenter in the heater section.

[rstrouse]

Your polarity is correct... Yellow D+ and Green D-. The other thing that happens when these are reverses is the bits are flipped 1 is zero and zero is 1.

Slowing it down a bit just gives the pi some room to breath. I'm running on a liquid cooled 16 core processor. Too bad we can only communicate at 9600 baud. The numbers you were seeing in red between byte counters was the number of outbound messages still waiting to hit the wire.

When it is done pounding through the address ranges it will trim a byte off the left and start hitting it with a new payload. This is very promising in that we have a response on action 80. I think my initial tries omitted the 15 and 12 addresses for crying out loud. And the communication source was fixed to a control panel starting on 16. In this instance it looks like 0 is the source with the force.

@theRealMCQwerty actually had a similar result but I wrote that off as bad comms. I have sent nearly 5 million messages to the valve explicitly avoiding these addresses. The only reason these were hit was because I didn't start it all at a minimum address range. The next thing I was going to have you guys do is change the source address so it communicates above the less likely lower addresses. Much less 0 of all things. Looks like I need to create another method that bangs the heck out of it using 80 as the action and 0 as its source address.

That's just so unlikely. So what has happened here is that we said "Hey Groot do something... you know the thing" and it responded "Ok." I'm not sure what we asked it to do but I do know how to find out.

[Amigaman68]

My new rs485 donle should be here tomorrow, hope i can get in on the fun

[thumbnut]

And what fun it is! I have heard not a click from the prisoner.

[gw8674]

rstrouse, I can see that you have been super busy with all of this, this afternoon... When you have a breather, can you take a look at my messages and see if you might have an idea on why I am not getting anything from the IntelliValve? I have been through the readme and can't figure out where I might have went astray.

ITMT, I'm going to go out and connect up another valve just to see if it might just be a faulty valve that doesn't want to communicate for some reason. Thanks much!!

[rstrouse]

@gw8674 I have some code that I will be posting up shortly that I would like you to try out.

@thumbnut wanna bet that the 240 message just spit out a series of information stored on the valve. Let's see if we get that when the payload is trimmed to 6. We have seen 240 spit out 1,2,255,255,48,91,32,1,0,64 twice now. If it does this when the length byte is 6 then woohoo!

[rstrouse]

@gw8674 are you seeing anything in the console? Double check your wiring. Yellow to D+ and Green to D-. I still have an update coming.

[gw8674]

Well looks like my Valve #6 didn't want to play nice. I went out and connected up Valve #5 and lookie here...

[gw8674]

I bet i know where the problem for that valve is too. I ran the cabling for most of my valves in conduit and through low voltage junction box etc. I bet on one of those crimped connectors (for one of the RS-485 conductors), I have a bad connection. I'll deal with that later... Here is my first response.

[gw8674]

Why is it when troubleshooting, that the thing you tried last, you wish you had tried first. That rascal "Murphy" got me again! 🤣

[rstrouse]

@gw8674 Well I would call that proof positive for the action 80. If you want to hear about a guy who's gears have been stripped so bad that he is shiftless. Try the guy who has sent ridiculous numbers of messages off to a lump with pretty lights only to have the folks that haven't reconfigured the software to start at the likely addresses (who by the way would have gotten no response if they did) get the valve to wake up. What I want to see now is you getting to 240 and having it respond after the first byte is trimmed.

[gw8674]

@rstrouse, So you want a screen print of the response when I get to Groot #240? I'm still at #40 with sent messages at 24,600 now.

[rstrouse]

Yep I want to see it whenever any of you get a message in the responses. We at least have it farting and burping instead of barking out "I am Groot!"

[gw8674]

Okay, sounds good. Yep, still only have two messages so far (the same two as my last screen print).

[thumbnut]

@gw8674 It took me all day to get the third one. I may have to put a fan on my poor little pi. It is certainly earning it's pay. And the stupid actuator is playing rope-a-dope. @rstrouse is right - we should approach the Karate Kid technique and FOCUS. I'll take even numbers.

[gw8674]

@thumbnut Cool. Thanks for the heads-up...
LOL... Yea, I can see the activity light on the serial-USB adapter flashing away at mach speed. I threw a Dual Fan Aluminium Alloy Heat Sink and higher grade thermal pads/compound on my RPi-4 when I got it back at the end of April. It's inside though, so it shouldn't get too hot, but it's definitely working.. 😆

[gw8674]

Interesting. I'm still getting lots of the following messages on the console. info: Serial port: /dev/ttyUSB0 request to open succeeded without error error: Serial port /dev/ttyUSB0 recovering from lost connection info: Serial port: /dev/ttyUSB0 request to open succeeded without error error: Serial port /dev/ttyUSB0 recovering from lost connection

But it's still churning away.

Also, the two responses that I've got so far, I've noticed this corresponding message on the console as well. info: We got another message 165,1,16,0,1,1,80,1,8

[rstrouse]

The results of today have built a new fork in the road. I expected all this to run for a few weeks before we got a byte (bad pun). I now have two byte patterns that are likely suspects. I want to keep the current patterns running until we get a few samples and the grooter switches over to the next pattern match automatically. This is important to make sure the valve isn't just ignoring the address bytes for some of its messages. As of now it appears to respond on two unlikely destination addresses (12,15) from a source that I thought would be undefined (0).

One of the actions we have uncovered is 80 in which the valve clearly just says Ok. That "in" message is what is know as an ACK. It is just responding and telling us that it got the command 80 successfully processed it. When you see an action 1 with a payload containing the action you sent then this is classical Ok.

The other is action we have discovered is 240. In this case the valve is responding with an action 241. This is telling us that 240 is a query message and 241 contains the information we asked for. The first 8 bytes of this message appear to be our groot payload while the remaining 10 bytes are 1,2,255,255,48,91,32,1,0,64. This my friends is data from the valve. We've had two instances of this and in each case it is the same payload. At this point I think everyone is in auto mode for the valve. Another note on this message is that it only appears after we have stripped the first byte from the payload. This means that grooter has sent it a message with the groot signature sans the first byte.

[rstrouse]

@gw8674 I have added code that should make the "recovering from lost connection" go away. I believe what was happening is that when the serial port doesn't get read activity it assumes there is nothing out there. Our groot messages can be several minutes apart and I can see where the serial port might think that nobody is home. I changed the code so that it no longer makes that assumption so it won't close the port and reopen it. You will need to stop grooting and update valve-Grooter. Don't worry it will just pick up where you left off.

[thumbnut]

More progress. Another 240

[gw8674]

@rstrouse, Okay.. We'll do. Should I stop it first and if so, what's the preferred method?

[gw8674]

And before I do that, looks like I have a third response now.

[theRealMCQwerty]

I leave you guys alone for a few hours and wow!

We at least have it farting and burping instead of barking out "I am Groot!"

@rstrouse got some more farts and burps for you. My old 'air-cooled' i7 is giving the prisoner a good what for and he has blurted out the following:

I'm in Auto mode btw.

[rstrouse]

So @theRealMCQwerty is consistently getting information on 240 even after stripping the groot identifier off the payload down to 3 bytes. I can only guess at this point, but wanna bet that the 240 message is a general message that asks all the valves to report their status? If that gets down to 0 bytes in the payload then that is the most likely case. He is down to 3. 80 with the appropriate settings may just be turning our valve.

@gw8674 to shut it down simply go to the nodejs console and hit CTRL+C. This will close the process and free up the resources. Then do a git pull while in the valve-Grooter directory. After that do npm start.

[theRealMCQwerty]

He is down to 3

Looks like I will have to stay up to 3AM to find out at the current rate. 😆

[rstrouse]

@theRealMCQwerty you're welcome... heh heh heh.

[gw8674]

@rstrouse Okay, so I did all that and I got the listening messages on the console but then it just sat there doing nothing and no activity light on the USB-Serial adapter. And so I walked out to the panel, momentarily killed power to the IntelliValve and came back in and it was churning away again. Wonder why it needs a hard power reset to get it going again? And yes, it picked up right where it left off on the Message Grooter...

[gw8674]

Just got my fourth 240 response. Yes, in auto mode.

[Amigaman68]

does this only work on a pi

[Amigaman68]

Dam it missed you had to have a pi

[theRealMCQwerty]

does this only work on a pi

Nope, works on anything that runs nodeJS. I'm running it on a Windows machine.

It was very easy to set up. If you have a machine running the nodeJSPoolController, just clone the valve-grooter repo, run npm install then npm start and you can join in the fun. Well, you need to set the port in the config and connect your dongle... just read the readme 😄

[rstrouse]

I’m running on Windows 10.

[rstrouse]

@gw8674 me thinks impatient you are. Use the force young Skywalker. It can take several minutes to get your first groot and we don’t start interrogation until the prisoner starts to talk.

[thumbnut]

What is the smallest delay we can get away with? I have a very fast windows 10 machine. I may be better off setting this up on it versus the pi. Is it too fast for the valve? Won't help if I have to have the delay but @theRealMCQwerty seems to be smoking me on his i7. This would be a great Intel/AMD matchup. Hope i didn't just start something. ;-)

[Amigaman68]

What did miss installing

[theRealMCQwerty]

@thumbnut Bring it!!!! 😆 BTW, mine seems to be speeding up, hit the 2 mark 25 mins ago 😄

[rstrouse]

Did you do a git clone first? Then npm install from the grooter directory?

[thumbnut]

@theRealMCQwerty What do you have for a delay in config.json?

[rstrouse]

@thumbnut thats not fast. Just kidding. Anything less than about 100ms delay tends to not allow the valve to speak.

[theRealMCQwerty]

@theRealMCQwerty What do you have for a delay in config.json?

Hmm, I don't have a delay in my config. I just used what was in the repo, set my com port and went for it

Edit: Added config file for ref config.zip

[rstrouse]

You just can’t set it in your version. It used to be hard coded to 100ms.

[thumbnut]

What is the cadence between "Last Message" and Last Verified"? My message stream is about 10 per second but verified is 10 to 15 seconds apart.

[theRealMCQwerty]

@thumbnut I'm getting a new Verified message about every 5 seconds I would guess I am sending about 10 messages per second also

[Amigaman68]

getting closer

[rstrouse]

That’s pretty chatty for the valve maybe those 240s has it broadcasting more often.