Closed theRealMCQwerty closed 3 years ago
@rstrouse I have all the needed hardware an am totally up to "crowd-grooting".
Later tonight I will package up the code. We should make sure we are not duplicating efforts so each one of us should declare which mode they are running on. I claim Auto. There are 3 other modes.
I have all the needed hardware an am totally up to "crowd-grooting". as well
Well aren't we getting all SETI on this.
Do you have such a setup?
That is exactly the setup I had back when we first started testing this out. I still have all the parts around and can easily set it back up again to commence Grooting-at-home!
@rstrouse not sure how much work this would be but since there are a few of us, could we also divide up the message space to maybe exhaust the most likely mode/message sets first then we all switch to another mode and run our own respective message group, or we all move to another message group based on perceived probability of success?
Good idea I have set up two distinct patterns. The key would be to take the assignments and break out the address ranges. When I get the code posted up we will divvy up the assignments. As it stands right now I probably need to add a page to check on the status as right now I am watching a file. It'll be ugly but it will display the underlying data.
Ok guys so I posted the valve-Grooter up on github. You can pull it install it then check to see if you have your environment set up. Then let's take a role call to see where we stand,
r., Would it be okay to leave an existing IntelliValve (not a bench test actuator) plugged in to its 3-pin socket on the valve expansion module to get power and then just connect the two RS-485 wires (grn/yel) to the RS-485 to USB adapter connected to the rp?
@gw8674 Yes that should work like a charm. As far as connectors I bought some male jst pigtails for the power side so I don't destroy the connector and some female jst for the RS485 pins. They work great and will be what I hook the valve up to the relay controller with.
Here are the connectors I bought. RS485 Pigtails for connection to port expansion module JST Power Connector for IntelliValve I think these are are ones I bought. I did it a while ago.
@rstrouse Cool, I'll start working towards the goal. I didn't know the name of those connector types. I looked up 2-pin female jst connectors on amazon and there are tons of choices. I always wondered how I would find the right connectors to use to connect the two RS-485 wires from my IntelliValves to my Serial Com Expansion Board once the IntelliValve RS-485 mystery was solved. Now I know... Thanks!!
I bought some male jst pigtails for the power side so I don't destroy the connector
You are fancy, I just jammed male dupont cables in mine. 😃 Got to rough 'em up a bit if you want 'em to talk!!
Anyway, I dragged my test valve out of solitary, strapped him down to my test bench, assaulted him with dupont cables and shone my desk light square in his face. I said "you WILL talk" and I hit enter on npm start
. Through gritted cams he replied "I am Groot!" with a defiant inflection to his bytes.
Awaiting further instructions Sgt. @rstrouse . Let's do this thing!
Hmmm, a problem.
Getting Error opening port
Access denied
.
Everything works fine for a while (a few minutes) then I just get these never ending access denied messages.
The message count keeps going up but the 'Groots` count stays the same, I assume because we are no longer really connected. I tried switching to a different USB port to get assigned a new COM port but same issue. The only way I can clear the error is to reboot the IntelliValve. But then the issue comes back again a few minutes later.
I am running an i7 laptop with pleanty of poke, do you think I am overloading the valve or the dongle?
@theRealMCQwerty yeah you are not overloading that laptop and yes we are sending messages but it is not going anywhere but I am confused that there is actually an inbound message response. And it's a response that kinda makes sense.
As for the groots they can be delayed for several minutes so yes there are very few groots for messages sent. The last verified message is set when a groot message is received. What is disappointing is the access denied on the port. Is this an FTDI or CH43 chip? Also what mode is the valve in?
Is this an FTDI or CH43 chip?
CH43, it looks like this:
what mode is the valve in?
Currently in Auto mode.
there is actually an inbound message response.
I tried it again but using my pi this time. No responses 😕
But I am getting some strangeness on the console:
Just for shucks change the port in config.json to for Windows to... and in the Hardware Manager driver settings make sure it is set to 9600, 8N1 and no flow control.
"rs485Port":"\\\\.\\COMX"
where X = the port number.
so far, so good....
Well look at that goofiness. Wanna bet that the dongle doesn't clear its registers when it is plugged in? Let her rip for a while then lets change you over to running in set mode. When you do that, close the applications then delete the equipmentConfig.json in the data directory. It will then start over from square on the lbytetrim method.
I am flashing a brand new rpi this morning. Should have the setup ready for Groot interrogation this afternoon.
Just for shucks change the port in config.json to for Windows to... and in the Hardware Manager driver settings make sure it is set to 9600, 8N1 and no flow control.
"rs485Port":"\\\\.\\COMX"
where X = the port number.
Thanks for the heads up on the port issue. I have the same dongle.
@rstrouse is this a Groot message?
If so, how do I know what is a Groot message and what isn't since the highlighted message received is slightly different from the Groot Message
shown at the top?
That is definitely not a Groot. However, take a read of the readme especially the section on Things we know about Groot. The padding at the start may just be the valve burping out a reply. This is likely a lucky collision where the scramble of bytes adds up.
my rs232 to 485 adapter appears to be dead so i have ordered a new one it will be here tomorrow.
Things we know about Groot
Ok, I read it before and read it again... 🙂 So I think you are saying that if the message does not exactly match the Groot message for my particular valve then it isn't a Groot message. But in this case the valve just sent out a garbled reply that just so happened to equate to a valid message?
Now that you have a better understanding of what we are looking at. The padding contains a complete Groot followed by a 255,0,255. This tells me that the CH340 chip experienced a buffer overflow and threw the preamble at the end of the header and payload. We are making Foie gras by force feeding it so many messages at a rapid rate. Then it drained its buffers with the message that we just sent it. Amazingly it all mathematically adds up and it tells me the valve is at least looking at what is on the bus.
Sadly, I know this failure pattern with what is known as a bi-directional buffer. I need a life.
Does this look like it is working?
Ummm... yes and that message [165,1,16,0,1,1] is what is known as ACK or acknowledgement that it received the message you sent it for action 80. Don't even tell me you guys hit a message after less than 5,000 sends.
I am having a horrible time uploading images.
The next question is "What mode is the valve in?" the question after that is "When the action gets to 240 are you getting another response?" I thought that @theRealMCQwerty was having comms issues and the responses in his screenshot were the sound that is made from the north end of a south bound cow.
I am in auto mode.
The valve is not doing anything. It is stationary at position 0.
I am getting the same strangeness as @theRealMCQwerty on the console. "...request to open succeeded without error", followed by: "...recovering from lost connection" I am passing 10 messages per second. I would post a screen shot but git is not cooperating.
Windows? If so make sure you change the settings in device manager. From a command prompt type mode comX. These dongles tend to ignore the settings from nodejs SerialPort. Also, make sure everything is connected before you fire it up.
I am watching the web output and it looks like a repeating loop. The bold 82 cycles at the same time as the 4,126 payload. The 82 goes from 0 to 255 The 3, xxx goes from 3, 0 to 3, 255 the 4, xxx goes from 4, 0 to 4, 120 Then this repeats. the first payload never starts at 0; it starts at 3, and never gets past 4 the second payload value never gets past 120 on 4 Should these be covering [255, 255] ?
[255,0,255][165,1,16,12,_82_,8][0,128,216,128,57,231,6,100][4,126]
Lastly, set the inactivtyRetry in config.json to 600.
How do I stop the process?
CTRL+C in the console or kill the node process.
No S just 600.
@rstrouse This is what I am getting... Thoughts? pi@raspberrypi:~/valve-Grooter $ npm start
valve-Grooter@0.0.0 start /home/pi/valve-Grooter npm run build && node dist/app.js
valve-Grooter@0.0.0 build /home/pi/valve-Grooter tsc
info: Server is now listening on 0.0.0.0:8986 info: Serial port: /dev/ttyUSB0 opened 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 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 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 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 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 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 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
@thumbnut it is running through all destination addresses in lbytetrim once it has exhausted all sources, destinations, and actions it trims a byte from the left side of the payload. And starts the process all over again.
Lets make sure we are speaking the same language though. Hit the readme as I added a section to the bottom that talks about the message data. I did this about an hour ago.
@rstrouse I did a restart on the pi and got something new. error: Serial port /dev/ttyUSB0 recovering from lost connection info: Serial port: /dev/ttyUSB0 request to open succeeded without error 172.22.56.43 GET / {} 172.22.56.43 GET /default.css {} info: New socket client connected 919gt5nM4ynyDWr6AAAB -- 172.22.56.43 172.22.56.43 GET / {} 172.22.56.43 GET /default.css {} info: New socket client connected 5cnhLVyJV9wtH3VGAAAC -- 172.22.56.43
But still no activity lights on the Serial to USB adapter. I'm going to go out to the panel (grrr, 113 degrees outside at the moment) and double check connections, power to the IntelliValve, etc.
Are the ip addresses supposed to be changed? It was working before without changing them. Now I am getting nothing in the web page. The browser seems to connect but nothing shows up. I have the rpi on the ethernet. The router sees it at 10.0.0.130
"http": { "enabled": true, "ip": "0.0.0.0", "port": 8986, "httpsRedirect": false, "authentication": "none", "authFile": "/users.htpasswd" }, "https": { "enabled": true, "ip": "0.0.0.0", "port": 8987, "authentication": "none", "authFile": "/users.htpasswd", "sslKeyFile": "", "sslCertFile": ""
@rstrouse Follow up on my deal, Actuator has power. Tried switching the two RS-485 leads around and also checked the connections. Nothing. Tried taking it out of auto mode and actioning the valve in service mode. Nothing. Tried actioning the valve in auto mode through the automation. Nothing. I have the IntelliValve Message Grooter page in chrome open but the page is blank. I think the IntelliValve is not communicating to the pi for some reason. Same RS-485-USB adapter that I use for the PoolController Dash panel. Haven't changed any config with the adapter. Any thoughts?
@thumbnut access it via http://10.0.0.130:8986 in your browser you should probably make a dhcp mapping in your router.
If that doesn't work change the ip address in the config to 10.0.0.130 Then you should be able to access it remotely. There are other options like accessing it through the machine name if your network is set up to do this. So http://raspberrypi:8986.
So I unplugged the Intellivalve and the process started back up. Apparently it hangs at some point.
I tried restarting the pi but no joy. Unplugging the power supply to the actuator and re-plugging got things going again.
@thumbnut power down your IntelliValve. I had instances where it would ... oh you beat me to it.
I also changed the IP address in the config to match the address shown by the router. Now I get a different console.
@thumbnut stop the application and change the delay property in the equipmentConfig,json from 100 to 200.
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?