Lucifer06 / RemoteGPIO

Remote General Purpose I/O for Venus OS devices (Cerbo GX, ...)
11 stars 3 forks source link

GuiMods / RpiGpioSetup conflicts #8

Closed kwindrem closed 6 months ago

kwindrem commented 6 months ago

I like where this is going but see an issue that we need to work together on:

The relay expansion beyond 6 relays requires qml file changes that will conflict with GuiMods. ​RemoteGPIO must always be installed after GuiMods in order to see relays beyond 6 but this is not guaranteed by SetupHelper/PackageManager. If GuiMods installs after RemoteGPIO then the relays beyond 6 will not show in the GUI.

I am more than happy to pull relay expansion out of GuiMods in favor of RemoteGPIO but RemoteGPIO needs to support the relays present on Victron GX devices as well as the 6 provided by the Raspberry PI platforms added by RpiGpioSetup.

I'm not sure if RemoteGPIO will install on Raspberry PI but it really needs to if it does not already. At that point, there will be a conflict in modifications with RpiGpioSetup which adds 6 relays for the PI as well as 5 digital inputs.

RpiGpioSetup modifies relaystate.py (part of systemcalc) and this conflicts with RemoteGPIO.

I can easily incorporate the changes from RemoteGPIO into RpiGpioSetup and also into GuiMods but maintenance then becomes an issue.

Currently, if one package modifies a file, a second one will override the first one's modifications and there is no way to guarantee which package installs first and second!

A conflict check could prevent overriding another package's modifications but this won't address the real issue that two packages need to modify the same file. Uninstall also needs to be tolerant of install conflicts.

I'm open to suggestions for PackageManager.

Comments please

Lucifer06 commented 6 months ago

Hi Kevin,

I initially thought that claiming the prerequisite of having Guimod installed first would be sufficient. And I agree I have to modify iml pages that got updated from your side. But may be I can find a way to check this is installed before proceeding with RemoteGPIO setup: for example by checking the presence of the Guimod folder in /data, or may be you can leave a flag in your setup folder to confirm this is installed, not only downloaded? Regarding rPI support, I don't see any reason why it would not work. And given that I will also add the TCP support in addition to the USB one, I'm pretty sure it will raise more interests, including the Raspberry users. I'm right now after the TCP support and then I will update the setup for a nice and clean install with PackageManager. I'm travelling all next week, so I think I will probably able to release the first package in 2 weeks.

Have you already started to work on Victron's GUI V2?

Cheers, FreD.

kwindrem commented 6 months ago

There is a way to see if GuiMods is installed. Look in /etc/venus for installedVersion-GuiMods. If that file exists, GuiMods is installed. However I would not make its install a requirement to actually install RemoteGPIO. There is no way PackageManager can prioritize installs. So if RemoteGPIO install is attempted before PackageManager gets around to GuiMods, then RemoteGPIO install would fail.

RemoteGPIO is adding more Relay overview pages and adding additional relays to PageSettingsRelay.qml so just having GuiMods installed is not sufficient for more than 6 total relays. So either we need to find a way to insure RemoteGPIO installs after GuiMods does (including a GuiMods update), or we'd need to incorporate RemoteGPIO relay expansion into GuiMods.

I'm considering changes to SetupHelper to 1) identify installation conflicts and 2) prioritizing installs so that for example RemoteGPIO could override GuiMods changes to the overview pages and PageSettingsRelay.qml. I'm not there yet however. I'm also paying with using unix patch to make changes. This would minimize conflicts but would not help in this case since we are both modifying the same section of code.

Regarding the additional overview pages: I recall someone having difficulty with adding additional overview pages. Apparently, there is a limit but don't remember what it is. 10 or less but maybe as low as 5 or 6. You may need to make Relay overview subpages with buttons to switch between them. gui-v2 is working on "zoned scrolling" where a region alone the sides will swipe between pages and areas inside this boarder will scroll within the page. So could potentially have one really overview page that scrolls relay tiles left to right.

For the RPI, gpio_list is in a different format:

# Relay 1   GPIO 21 / header pin 40
21  out relay_1
# Relay 2   GPIO 17 / header pin 11
17  out relay_2

# Relay 3   GPIO 27 / header pin 13
27  out relay_3
# Relay 4   GPIO 22 / header pin 15
22  out relay_4
# Relay 5   GPIO 23 / header pin 16
23  out relay_5
# Relay 6   GPIO 24 / header pin 18
24  out relay_6

# these have pull UPs
# Digital input 1   GPIO 5 / header pin 29
5   in digital_input_1
# Digital input 2   PIO 6 / header pin 31
6   in digital_input_2

# in stock code these have pull DOWNs
#### modified to pull UPs by the GPIO overlay that is installed as part of this package

# Digital input 3   GPIO 13 / header pin 33
13  in digital_input_3
# Digital input 4   GPIO 19 / header pin 35
19  in digital_input_4
# Digital input 5   GPIO 26 / header pin 37
26  in digital_input_5

I'm not sure that format would work interchangeably with the one used on Cerbo, etc. because don't know how the Cerbo format is filled in. It may be that RemoteGPIO and RpiGpioSetup become mutually exclusive. You either get relay AND digital inputs over USB or TCP/IP or get to use the PI's GPIO pins. For this to happen RemoteGPIO will need to support digital inputs which I'm not sure it does yet.

Regarding gui-v2: I am not looking at this right now. The current design requires compiling the GUI code which is then installed on the GX device as a single executable. (Actually two because the remote GUI has its own WASM file that is downloaded to the display device.) Supporting multiple firmware versions as well as packages from multiple authors is all but impossible. Victron has promised to provide a solution but has to get gui-v2 fully functional before they can devote resources to design and implement third party support. I'm afraid coming up with a solution is beyond my capabilities.

Most of what I've done in GuiMods will be unnecessary with gui-v2 so I have no plans for a GuiMods for gui-v2. Victron has also hinted that they plan native support for relay (and possibly digital input) expansion and their own relay overview pages. So your efforts may not be needed in the future, but are for sure right now.

Lucifer06 commented 6 months ago

OK I will give a try with looking at /etc/venus. There maybe another elegant way with keeping a flag in dbus? Until we find a clever way to manage conflicts, better that the install of RemoteGPIO fails. Is there a way to display a message on the GUI if install fails?

RemoteGPIo do supports Digital Inputs. At this stage I have found a limit to maximum 9 digital inputs. Any idea on how to go beyond, bec1use I'm adding 8 DI with each modules...?

kwindrem commented 6 months ago

PackageManager does publish information on dbus which includes installed version which will be blank of not installed. The info uses the same index as that used for the PackageManager's Settings so you need to find the name of the package in Settings and use the same index in the info in PackageManager.

Right now, RemoteGPIO install won't fail as I have no conflict detection. The last package to install will overwrite the files modified by other packages. Obviously this needs better handling and I'm working on a design now. What I'm considering is storing the package name with each replacement. For example if GuiMods updates PageSettings.qml there would be a PageSettings.qml.package containing GuiMods. Then other packages would check to see if the file was already modified by another package and trigger a failure to install the second package.

All this logic would be in CommonResorces so the package setup script wouldn't need to change.

Install failures for manually installations are shown on the GUI. There is not yet a "package conflict" reason for failure but I will add that as part of conflict detection that would cause RemoteGPIO to fail.

Limits such as for digital inputs is a mystery. Something is obviously hard coded somewhere in the Victron code.

kwindrem commented 6 months ago

I made some changes to GuiMods to support 18 relays. I have not tested it but see what you think.

Overview Relays is a single page in which the relay tiles scrolls left and right. To swipe to the next overview swipe in the title. Archive.zip

kwindrem commented 6 months ago

I have updated GuiMods to support a maximum of 18 relays and also updated the Temps Tanks Digital Inputs overview to allow for additional digital inputs. The relay overview scrolls left/right if there are more than 6 relays in the system. Swiping in the title area will switch overviews.

If what I've done for the relay overview seems clumsy, I thought about maybe swiping pages of 6 relays vertically or installing page buttons.

Comments?

I suggest you remove the relay OverviewRelay.qml and PageSettingsRelay.qml from your package and I'll commit to keeping these up to date in GuiMods.

I'm recommending we insure that RemoteGPIO and RpiGpioSetup can not both be installed at the same time. GuiMods does force uninstall of older packages (ExtTrasnferSwith and GeneratorConnector) whose functions have been assimilated by GuiMods but I want to implement a general solution. I'm working on that now and will let you know when I have something.

drtinaz commented 6 months ago

Kevin, I see the additional relays in the Relay settings menu, with the option to name relays 7 - 18 but no option to "show relay on gui" like with relays 1 - 6 (I'm assuming the option to show only appears if the system sees that they are in fact installed?). I have updated relaystate.py, gpio_list, and services.json to add the additional relays (in my github RemoteGPIO_tcpip) and published release v2.9 with the changes, and installed it in my system. In node red I still only get relays 1 - 6 in the relays input and output nodes. I have verified that the updated files were in fact installed on my cerbo. Am I missing something? Or is this a limitation in the cerbo somewhere?

Edit...put a pin in this for now, I think I see what I missed. Pun intended.

kwindrem commented 6 months ago

I do see some bugs. The relay manual switch, show on relay overview and name should only appear in the menu if the relay is defined but some of these checks are missing or incorrect. I'll make these changes and get a GuiMods update out soon.

drtinaz commented 6 months ago

Kevin, after adding the pins I was able to get the additional relays to show on the dashboard, and in node red. In the dashboard if I scroll to the right to access additional relays out of the view, once I click on on/off and the state changes, the page reverts back to the first 6 relays. I would think it would be better to have the page view stay where the user put it. Possible?

kwindrem commented 6 months ago

I agree it should not scroll back to the first page. I'll look into it.

kwindrem commented 6 months ago

Scrolling issue fixed in GuiMods v10.6

drtinaz commented 6 months ago

Just an observation, but I noticed in the code it seems you have hard coded the modules to 8 relays and 8 DI each for a total of 16 & 16 across 2 modules. Can you consider making it configurable in the settings for the number of relays per module? For example I have 2 modules of 4 relays and 4 DI each, and one module of 2 relays and 2 DI. There are a few others on the forum that have also mentioned using different sized modules.

kwindrem commented 6 months ago

Might be better as a separate issue rather than part of RpiGpioSetup conflicts issue.

Lucifer06 commented 6 months ago

Great, I was looking for having the relay overview page to scroll but it was beyond my knowledge. I'll then remove my relay dosh board pages as I have no need to make changes of pages already modified by Guimod. Sorry guys for the delay to reply by I'm travelling in Africa with sporadic Internet and limited time. I'll look at this when I'll back this week-end, and hopefully manage to finish the setup script.

Lucifer06 commented 6 months ago

Just tested 10.6: I like it! And confirm I will remove the Overlay relay pages from RemoteGPIO, this is far more better solution.

kwindrem commented 6 months ago

Great. You should also remove PageSettings.Relay.qml as GuiMods is doing that for 18 relays also.

Next step is for me to prevent RpiGpioSetup from installing with RemoteGPIO since they both do similar things but would conflict.

Lucifer06 commented 6 months ago

OK will do the same against RpiGpioSetup. I would love that Victron provides a native external relay support. I did ask in one of these conference call a year ago and they said they were cooking something... So hopefully at some point it will be straight forward. Meanwhile I think we have here a nice alternative. Thx again for the great job you made with GuiMods and improving the relay page!

kwindrem commented 6 months ago

GuiMods has code in its setup script that uninstalls conflicting packages and sets them so they won't auto install. You could use this code in RemoteGPIO.

Also, I'm working on a mechanism within SetupHelper to handle this for all packages. I haven't worked out how this will work under the hood but it will start with a file in the package that assumes priority over the other(s) identifying which packages to uninstall and block.

Lucifer06 commented 6 months ago

Playing around the Relay Overview page I found that the font colour if wrong (normally displayed in black, but it turns white) if the custom name of the relay exceed 8 characters.

kwindrem commented 6 months ago

Nice catch. Thanks. Fixed in GuiMods v10.8

Lucifer06 commented 6 months ago

I'm closing this one as we have now a working solution with no conflicts.