Improving the USB plug & play function (serial-starter) #129
Comments
|
@jhofstee: pls review above before I assign it to someone. thanks. |
|
Above, you mention a manual for vebus But the link to manual returns 404, and Mk2-dbus - h does not show this option. |
|
@oldwindmill: it might be a compile option to enable that commandline flag. What platform / origin of the binary are you using? The repsonsible developer is on holiday. Perhaps @izak is able to figure this out in the meantime. |
|
This is the udev I use for the mk2 and mk3. It simply matches the ID_MODEL part advertised by the device and creates a symlink. There is another change (in meta-victronenergy-private) to make serial-starter skip the mk2/mk3, which will also be useful here. If you want, I can also look at the rs485 (cgwacs) one, I own that piece of hardware :-) |
|
The changes I made, for the Rapsberry Pi, is in the internal repo, on the WIP-rpi3 branch. The relevant changes are: b31e98 - small improvement on the way Somewhere in the past -- I think I deleted that code -- I had a solution that would skip a device IF a symlink to it existed already. The idea is that serial-starter would look for some kind of indication that the device was already handled. That is a more generic solution that would automatically ignore any device handled by udev, as long as udev created a symlink as part of the job. The trouble with that solution is that there is a race condition: It is possible that serial-starter notices the new tty device before udev manages to create the symlink. Unfortunately device creation cannot be overriden, nor can devices be renamed in udev, so a device node will always appear directly in /dev where serial-starter will find it. A possible solution is to put symlinks to all recognised usb-serial devices in a known place, and the unrecognised ones in another known place, and let serial-starter do the serial dance only for those who reach the latter. I'm just think out loud of course. |
|
@izak: you wrote:
I left that out of the list of recognizable devices (mk3-usb & vedirect-usb) on purpose. The reason not to autodetect the cgwacs/rs485 is that its too complicated to justify:
So, same as GPS, they'll need to be detected in the old style. But by adding a cache, it only hurts on the first boot. |
|
I assume the cache can be invalidated in some manner, probably by throwing it all away when an inconsistency is detected? Then it only hurts when you move/add devices. |
|
@mansr: fyi I've added the Redflow to the list, now that it is not (yet) obsolete anymore. |
|
I've pushed an overhauled serial-starter script to branch |
|
With @mpvader 's permission, I'd like to request that serial-starter detect the mk2/3 and explicitly skip it, do nothing. My solution on the raspberry pi is to add a udev configuration stub that detects the mk3 and symlinks it to a known location, where the vecan-mk2 process finds it. As long as serial-starter leaves it alone it works perfectly. It also works because you will (or should) only ever have one mk3 device. The alternative is to duplicate the vecan-mk2 service, stop the original (which auto-starts), then start the copy you made. This is perhaps more in the spirit of making a definite distinction between built-in hardware and usb hardware. I'm commenting here specifically because this is one of the final blockers for a full Raspberry Pi version. Don't have a preference and will go with what you guys decide, just making some suggestions :-) |
|
Skipping those devices in serial-starter should be easy enough. |
|
Is there a good reason to manage the fixed VE.Direct tty ports with the serial starter and at the same time not managing the fixed VE.Bus tty port through it? Note that, as discussed with @mansr, the plan is to add a command line option to the VE.Direct driver, telling it to never give up. Two services with that flag in their run file can then be installed for the dedicated VE.Direct ports. Either created by serial-starter, or perhaps more clean, in another way. Leaving serial starter to manage only the USB ports. |
|
There's certainly a case for managing all devices and services of the same type in the same place. A machine-specific config file could tell serial-starter what to do with built-in ports (fixed function, auto-probe, or ignore) while for USB devices this decision would be based on the product string. |
|
Another question, @mansr did you find out what the purpose of the special treatment of GPS-es is in serial starter? I ask because I now have a support request on system that doesn't recognize a GPS. I know there is a gps: But serial-starter is not trying the gps service: Fyi, while browsing around I found that Above system has these locks: |
|
I have an idea already: could be that the purpose is that there is to only have on gps-dbus service running at a time. See below for what happens in case multiple gps-es are plugged in and multiple services are running. Plugging in multiple gps-es is not a promoted or normal thing to do. |
|
I've tested here with two gps-es by starting the gps_dbus twice. The second service does not crash, but is connected to the dbus using a temporary name. Both services print out Service 1: Service 2: |
|
thanks, I've updated my comment above. |
|
Conclusion: in case a user plugs two gps-es in, which they shouldn't do in the first place, there is no problem in running the gps-dbus service twice: the second service to start will get an alternative dbus name. The processes using gps data (gui, vrmlogger, modbus tcp etc), will therefore simply not see it. |
|
Does gps-dbus claim the dbus service name only once it has detected a GPS device? Otherwise there could be a problem. Suppose there is a non-GPS device on ttyUSB0 and a GPS on ttyUSB1. Then the following could happen:
|
|
Gps: another reason to stop looking for gps-es once one is found could be to save detection time. But, that is only three times a few seconds, and with the new code there will be caching, recognizing vedirect USB ids, etc: also not such a strong argument to keep the gps.lock complexity in place. @jhofstee: do you know any other reason for the gps.lock? |
Yes, gps-dbus needs to see valid GPS (NMEA0183) output before it is actually claiming the service name |
|
OK, in that case is seems like dropping the lock should be safe. |
|
Hi Mans, I had a quick look at the committed code, I like it. I think there's two small things that jumps out at me:
Otherwise, +1. I love the way you delete symlinks once handled. |
|
I've made a few tweaks and also converted vecan-mk2. There's still a problem with daemontools trying to restart the service if its device is removed. |
|
And now that problem is fixed. |
|
Just loaded the 2.07~19 build serial-starter changes on my CCGX. Everything came up and is working, and this was the fastest I've ever seen the grid meter come up! It came up even before the MPPT, usually it was dead last. There is a vedirect_interface process trying to access /dev/ttyO2 (unused on my ccgx) that restarts in a loop, which I suspect should be started with the "forever" switch. That's the only oddity I see right now. Will build and test the Rpi version tonight. |
|
I've updated the branch with what is hopefully the final version. The vedirect-interface service now disables the timeout for known devices. There are also some other minor fixes and cleanups. |
|
Testing with a USB-connected mk3, I noticed a somewhat unrelated problem. If the device is unplugged, the mk2-dbus program doesn't exit but starts printing error messages as fast as possible. This is obviously not good, although in practice it should be uncommon for a device to be unplugged while the system is running. |
|
Feedback on the Raspberry Pi. It works with the master branch, but with the serial-starter changes the serial terminal falls over within seconds after booting. I can't for the life of me think what it might be, but I can debug it tomorrow once I have access to a screen and keyboard again. Hopefully it's something silly. |
|
Somehow the serial device /dev/ttyAMA0 -- the debug port -- is showing up as a serial port that needs to be handled and because no program is associated with that it tries the default two (gps and vedirect) which kills the debug console. That's probably because because the rules say Simplest solution might be to just skip them, although it feels cleaner to match them in the rules file and avoid creating the symlink in the first place. I'll test my theory on the beaglebone later, but I'm pretty sure the same is going to happen. |
|
Further to the above, on the CCGX there is no dedicated debug port, and the code handles the exclusion of |
|
Here is a possible solution. It's a "simplest thing that will possibly work" sort of solution that simply ships a slightly modified udev rule per platform. For the Rpi we simply ignore all platform devices, we only have one UART and it is used as debug console. For the Beaglebone, we ignore |
|
I see what's going on. The ttyAMA ports are reported under the "amba" subsystem rather than "platform" like most built-in devices. The udev rule matches a "platform" subsystem higher up in the tree while the script only looks at the device itself. I have updated the script to ignore any devices with an unrecognised subsystem which should take care of this with no further changes. |
This would require stopping it through daemontools and preventing serial-starter from starting it again. As the scripts look now, the equivalent of this shell command sequence ought to work: |
|
We'll have to check if that is sufficient for the beaglebone. On the beaglebone I half suspect it will incorrectly attempt to start vedirect and gps on debug port /dev/ttyO0. |
|
It works fine on beaglebone. ttyO0 isn't listed in /etc/venus/vedirect_ports so it is ignored just like all the other unused ports. |
|
Okay, so I'll test again on the Rpi, though I don't foresee any trouble. The two most important platforms are covered then. |
|
Tested again. Specific platform was an Rpi3 with official mk3 and vedirect cables. Works as advertised. 👍 from me. |
|
A few more improvements today. As requested by @mpvader, the main script now exports information on which ttys might provide each function. There are also scripts to stop/start services per tty as required to perform firmware updates. Additionally, the initial startup is much faster. |
|
@mansr about stop-tty.sh: That script adds a delay of 7 seconds. Which I suppose is there since there no quicker yet trivial solution. The 7 seconds is fine, but when having lots of possible vedirect ttys this becomes rather long. Can this be changed to feed multiple ttys to the stop script, and then do the sleep only once? So then the call would be |
|
Sure, that should be easy to do. It shouldn't be terribly hard to get rid of the delay completely either. If you're otherwise happy with it, I'll see what I can do. |
|
If the 7 second delay always works its fine, but besides it being a (only small!) nuisance for the user, we also need to make sure it doesn't create a bug. Either now or in the future. Am I right that when, for example, some new service takes longer than 7 seconds to detect something, this would create a bug? Its up to you, for me its fine if you spend a few more hours to take it out altogether, especially in case that also makes it more robust. |
|
The |
|
I have improved the scripts to get rid of the delay and also fix a possible race. |
|
great. I've added it for inclusion into the next release process. |
|
Was added in Venus v2.08~1 |
mpvader
changed the title
|
|
hi, I have a FTDI rs485 cable, I connected it to my victron GX color control but it doesn't work to read the ET112 smart meter, how can I program the EEPROM to make it work? |
|
Hi, sorry, but I don’t know by heart; we don’t support that. what you could try is ask on the Modifications section on https://community.victronenergy.com. perhaps there someone can help. But don’t be surprised if no one can, and you’re only option is to buy such cable from us. |
|
(Updated above) |
Venus supports multiple different serial protocols. The devices using those protocols can be connected to real UARTs and also via USB. There is a driver, not a kernel-driver, just a binary executable, for each different protocol, which bridges between the tty and D-Bus.
The plug & play implementation we have today is the famous serial-starter. In essence it just iterates through all possible drivers, starting them one by one against all available serial-ports: a driver will exit when it does not detect a device, and also exits when it looses the connection. This is a simple but rather crude and CPU intensive solution (by design :-)). Which is now getting in our way: by using so much CPU it limits the amount of devices that can be connected.
Note that the dbus-redflow entry in serial starter can be ignored: it is obsolete.
Dedicated ports
The CCGX and the Beaglebone-based product (named Venus GX) have a few dedicated ports: 2 x VE.Direct, and 1 x MKx (MK2/MK3/VE.Bus). Today, those VE.Direct ports are handled by serial-starter, and the MKx port is not:
USB ports
With above, the dedicated ports are out of the way, and what needs to solved then are the USB connected devices/protocols. The idea is to let udev do the work, and use the USB identifiers to filter out the two hard-identifiable, and also most used-, protocols:
any available tty ports that don't fall in above category should then be iterated over again. With three drivers: vedirect-interface, dbus-cgwacs and gps-dbus.
Also, instead of redoing the detection at every boot, it should be cached: if a certain product was connected to tty-such-and-so last time, big change that in the next boot it has remained the same. Obviously some more handling is necessary when introducing caching: devices can be disconnected while the Venus-device is switched off, or swapped, or ...
Note that the udev version in Jethro already has an advantage over the one in Danny. It lists tty's by id and by path:
There are five possible types of devices connected to USB:
1) mk2-dbus (aka vecan-dbus aka vebus_interface)
https://git.victronenergy.com/ccgx/meta-victronenergy-private/blob/master/recipes-ve/vecan-mk2_2.49.bb
The USB-serial converter is produced/programmed by us, and a special identifier is programmed into it. See below.
2) vedirect-interface
https://git.victronenergy.com/ccgx/meta-victronenergy-private/blob/master/recipes-ve/vedirect-interface_3.15.bb
The USB-serial converter is produced/programmed by us, and a special identifier is programmed into it. See below. Note that
3) dbus-cgwacs: Carlo Gavazzi energy meters on a RS485 bus
https://git.victronenergy.com/ccgx/meta-victronenergy-private/blob/master/recipes-ve/dbus-cgwacs_1.8.0.bb
The USB-RS485 interfaces are sold to customer by Victron, so we have some control over them. But they are not programmed with a special identifier. There are three options:
4) gps-dbus: nmea0183 gps
https://git.victronenergy.com/ccgx/meta-victronenergy-private/blob/master/recipes-ve/gps-dbus_1.02.bb
https://www.victronenergy.com/live/ccgx:start#connecting_a_usb_gps
These are off-the-shelf devices, which cannot easily be recognized by their USB identifiers.
5) dbus-redflow: Redflow batteries, connected via RS485
https://github.com/victronenergy/dbus-redflow
The same type of USB-RS485 converters are used as for item 3, the dbus-cgwacs Energy Meters.
USB identifiers
1) lsusb -v on a mk3-usb
2) lsusb -v on a properly programmed VE.Direct USB cable
3) lsusb -v on a not properly programmed VE.Direct USB cable.
During some time (months/years) we made a mistake in programming the usb-serial converter chips: the data was written to the chip, but not a proper checksum. Note that the returned info still differs from an original ftdi chip that has a proper checksum. Still the idea is to not try to detect this. It adds complexity, and the caching feature will eliminate the extra cpu usage anyway.
The text was updated successfully, but these errors were encountered: