Dan tells me that the s10 and s15 Victrons are hooked up and talking over their Bluetooth app. I tried logging into s10 and get the message that the port "isn't open yet". In a rash attempt to try to reset this (USB) port, I rebooted. s10 is sending data again (still not from the Victron), though I've now also lost the ability to log in via the tunnel. I note that the tunnel just didn't respond for about 5min, then finally started giving "connection refused" messages...
daq@s10:~/isfs/projects/SWEX/ISFS/config $ rs /dev/ttyPWRMONV
connecting to inet:s10:30002
connected to inet:s10:30002
sent:"/dev/ttyPWRMONV
"
line="OK"
parameters: 19200 none 8 1 "\n" 1 0 prompted=false
:Take it easy Stumpy! s10:/dev/ttyPWRMONV is not open (yet)\n
If it helps, I also did "lsusb":
daq@s10:~/isfs/projects/SWEX/ISFS/config $ lsusb
Bus 001 Device 008: ID 0781:5575 SanDisk Corp.
Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 012: ID 1410:9030 Novatel Wireless
Bus 001 Device 006: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 005: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 004: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
2 Comments
Gary Granger
The problem was that the udev rules which create the /dev/ttyPWRMONV device had not been installed yet. NIDAS rserial reported the device was not open yet, but it was not open because the device did not exist.
There is an ansible playbook which installs the rules, so I've run it for s10:
Now the Victron data are being recorded. We'll probably need to do this for other DSMs, but at the moment s10 is the only one I can reach.
As to the ssh tunnel, when it hangs but doesn't connect, that is usually because the DSM has died or lost networking without being able to close the tunnel first. So the ssh session and port on eol-rt-data is still open, but there is nothing to connect to on the other end. Eventually that connection times out and the tunnel port is closed, at which point connection attempts get the "connection refused" message. The tunnel connection is attempted every 12 minutes, so hopefully it should never take more than 12 minutes to re-establish the tunnel.
Gary Granger
s4 and s15 have been fixed.