Replies: 33 comments 36 replies
-
|
I've made pretty good progress so far. I have added an "Additional Options" menu for each module, which contains toggles to enable/disable reading relay state and digital inputs. I think that the "Module Reboot" should also be moved into this sub menu. I have also added an option to "Restart RemoteGPIO" on the main RemoteGPIO settings page. This makes it possible to make any changes to the configuration without having to reboot the GX device. One issue I have run into is that when digital inputs are disabled, the string value for the latency is not being read properly after a reboot. A restart of the driver fixes it but I can't see anything that would cause it. I might try adding a sleep delay at the top of the driver to give more time for the settings to load but I can't see that being the issue. For now I have just set the latency to a static 0.2 until I get through the testing phase. If you want to have a test run the GitHub is as follows: I know you are currently travelling, as am I. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Thomas we are in agreement, I don't see any benefits to have dynamic i/O configuration.I'm in LA flying back home today...Cheers,FreD. Excuse possible typo: swallowed by my iPhoneLe 18 avr. 2024 à 07:45, Derrick ***@***.***> a écrit :
I didn't realize I was replying to your announcement when I should have started a new thread. Anyways, here goes.
Hello Frederic. Since you went through the effort to open this discussion board I thought I might as well start using it. This regarding our previous discussion concerning high system resources usage and possible freeze-up and reboot when using three modules.
I have made pretty good progress in my limited time testing. I have been able to reduce the overall CPU usage by 65 - 70% by making a few changes to the service and driver. I am going to continue testing. I would also like to make a few changes to the RemoteGPIO settings menus such as adding the ability to enable/disable reading external relay state and digital inputs for each module individually. I would also like to add a menu option to restart the rgpio service from within the menu for the following reason. I removed the dynamic updating of number of units and number of relays from the service loop as this was the highest usage of overall CPU usage and system resources, and added a one liner to run S90rgpio_pins.sh at startup before the loop. This alone results in a 50% reduction in system resource usage. I have tested this to work properly upon system reboot and firmware upgrade. What do you think? I don't want to spend a lot of time on changing/adding menu options if you are not in agreement.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Derrick, I'm Craig pleasure to make your acquaintance. Not a GitHub expert by any means, do we start a new branch for dev team? My work has solved the Digital Input issue on the Pi and Derrick's work, is obviously a huge issue. Finally have my Cerbro GX MK2 and see just how horribly under powered it is, compared to the Pi 4 Model B. After installing on the Cerbo, it just cripples it. Run's like a clock on the Pi. Still working on the dbus-digitalinput.py script tracing couple times and hour. Good chance Derrick's work will resolve this. From the sound of it, he's addressing the very issue that's throwing the the exception on the Pi. Going to pull his repo as I type. Let's pull this team together and make a rock solid solution for all to use and enjoy. |
Beta Was this translation helpful? Give feedback.
-
|
Fredrick wrote Thomas, is that Derrick? Now I'm all confused :) We'll get the names all worked out. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
Derrick is my first name, Thomas is my last name. Either one is fine. I get that all the time since both are common as first names. |
Beta Was this translation helpful? Give feedback.
-
|
Settled I’m calling you Derrick. Do we know if this works on the Ekrano? Gut says yes since it comes 2 Digital Inputs, and passes start-digitalinputs.sh test, that was killing it on the Pi. I’ll be getting one here shortly, for no other reason that this Cerbo GX MK2 is such a CPU bound mess. There’s no way it’s going in my new house, not a chance. I didn’t get a chance to pull your work last night, very interested to see what you’ve been up to. If by chance it doesn't solve my exception issue on the Pi, it'll at least point me in the right direction. Cheers, |
Beta Was this translation helpful? Give feedback.
-
|
I'm still travelling today, I will be home this evening and then I will have more time over the next few days for further testing and finishing up on some enhancements and refining the services. Should make it run a little better on the GX platform. It should work on the ekrano as they are essentially the same OS and platform. Difference would be that there would be no digital input 3 and 4 since the ekrano only has 2 and RemoteGPIO installs 5 and up according to the configuration. It would probably be possible however to modify the S90 script to accommodate the different numbering schemes according to what device is being used. It could either run a check to see which platform it is running on, or add a setting to select the platform. What do you think @Lucifer06 ? |
Beta Was this translation helpful? Give feedback.
-
|
BTW, @cbelcher if you think it's sluggish on your mk2, you should see it run on my production system. I have parallel MP2, 2 mppt's, 2 smart shunts, 7 tank sensors, 6 temp sensors, 3 relay modules, and bms all running on the mk1 with guimods. Talk about sluggish. If I run the modules through tcp in node red they are really snappy, but I have been working on trying to 'trim the fat' on the Dbus version as I would really rather run it natively without depending on node red. I find that the service and the driver use minimal CPU but the other resources being used by the driver and service is what really taxes the CPU. |
Beta Was this translation helpful? Give feedback.
-
|
Restarting the service to handle big changes is probably OK but should be automated. Your code can trigger a restart when it detects changes to the associated dbus parameters. The simplest way to restart is to exit from mainLoop. The script will then exit and the service will be restarted. I'm not sure I see the need to read relay state values from the relay box. This should be one-way communications: GX should always set the relay value and there should be no other systems controlling the same relay. One thing I've done to reduce execution time is to keep local values for dbus parameters. If dbus parameters can change from outside the program (eg values set by the GUI), I use the dbus change handler to update the local copy. If you are setting a dbus Setting parameter often, you may need to slow that down to avoid time in the non-volatile mechanism. As an example the generator code does this. It keeps a local variable that's updated frequently, then the dbus Setting is updated from that every 30 seconds (or something like that). If you need a dbus value to be more up to date, create a parameter in your service and use that everywhere. The Settings value is only there for non-volatile storage. This is what is done for the relay states so they are restored after a restart. But the value in ...system is the working one. CCGX is far more limited in processing power than Cerbo. So you either need to address CPU usage on CCGX or specifically block install of your package on that platform. Yes, RPI 4 has more processing power than Cerbo so you need to test CPU utilization on that. Keep in mind gui-v2 is also gobbling up CPU bandwidth so I'd check with that running locally also. A remote gui-v2 actually runs on the platform hosting the display, not on the GX device so you need to run gui-v2 on the local display. You might also look into multi-threading your service and scheduling different activities at different frequencies. PackageManager runs several threads, many of which wait on something placed in the thread's queue. Separate threads can reduce the tasks your main loop has to do every second. I use a timer to measure execution times so I can identify where to focus efforts to optimize performance. PackageManager's main loop has such a timer (commented out) that you can use as a template. |
Beta Was this translation helpful? Give feedback.
-
|
I have already removed a lot of the code that restarts the service automatically on Dbus changes and now the service only restarts by a manual selection in the settings. Configuration changes no longer restart the service. As far as reading relay state, there may be some situations (I have several) where the relay may be switched from an external source such as a wall switch, and the gui has no way of knowing the state has changed. Some major changes have been made on my dev branch. Still a work in progress. |
Beta Was this translation helpful? Give feedback.
-
|
This was your last email I think I see others.
Man been on a network down all day. Entire Florida electric grid, they can monitor all the substations. Boy talk about pressure.
A work in progress, for sure. But I’m having fun.
From: Derrick ***@***.***>
Sent: Friday, April 19, 2024 3:06 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
I have already removed a lot of the code that restarts the service automatically on Dbus changes and now the service only restarts by a manual selection in the settings. Configuration changes no longer restart the service.
As far as reading relay state, there may be some situations (I have several) where the relay may be switched from an external source such as a wall switch, and the gui has no way of knowing the state has changed.
Some major changes have been made on my dev branch.
Packagename:RemoteGPIO username:drtinaz branch:dev3
Still a work in progress.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNILUEIKAWH25HGG7CTY6FTI7AVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZQGE4DK>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
I have made enhancements on the dev3 branch. Now ready for beta testing. |
Beta Was this translation helpful? Give feedback.
-
|
to all, I have merged the dev3 into the dev branch. If there are no issues and @Lucifer06 approves of the changes I will push to the main branch. For now you can give it a try @ package name:RemoteGPIO username:drtinaz branch:dev @Lucifer06 I temporarily removed the user setting for latency as I was having issues with the string not loading after a reboot. I have set sleep 0.1 which seems to be fairly snappy. Any more than that and the delay between switching on the gui and the relay changing state becomes noticable. The difference in CPU usage between 0.1 latency and higher seems to be less than 1% so I don't see the need to add the user setting back into the menu. What do you think? I have discovered what was causing the latency not to load properly so I can add the setting back pretty easily if you decide that would be beneficial. And lastly, the changes I have made here have resulted in an overall CPU usage reduction of up to 75% for the package. I have been running it on my very busy cerbo and have had no freeze ups or reboots. The system can get a little sluggish from time to time, but that's most likely just because of the number of devices I have connected, and some extensive node red flows. Feedback is appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Derrick what’s your GMT offset. In Tampa (this week it’s) -5. They’ve tried to kill it for decades this insane practice of changing the clocks twice a year, it’s maddening.
I’m guessing Fredrick must be +1’sh in good old France?
Was meaning to ask, you doing your testing on a Cerbo? I’m only 4’ish months from, even knowing this company existed. Now that’s a rookie, for you 😊
Cheers can’t wait to pull and test.
From: Derrick ***@***.***>
Sent: Saturday, April 20, 2024 11:48 AM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
to all, I have merged the dev3 into the dev branch. If there are no issues and @Lucifer06<https://github.com/Lucifer06> approves of the changes I will push to the main branch. For now you can give it a try @ package name:RemoteGPIO username:drtinaz branch:dev
@Lucifer06<https://github.com/Lucifer06> I temporarily removed the user setting for latency as I was having issues with the string not loading after a reboot. I have set sleep 0.1 which seems to be fairly snappy. Any more than that and the delay between switching on the gui and the relay changing state becomes noticable. The difference in CPU usage between 0.1 latency and higher seems to be less than 1% so I don't see the need to add the user setting back into the menu. What do you think? I have discovered what was causing the latency not to load properly so I can add the setting back pretty easily if you decide that would be beneficial.
And lastly, the changes I have made here have resulted in an overall CPU usage reduction of up to 75% for the package. I have been running it on my very busy cerbo and have had no freeze ups or reboots. The system can get a little sluggish from time to time, but that's most likely just because of the number of devices I have connected, and some extensive node red flows.
Feedback is appreciated.
—
Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNNZR64LTXIAFSIPAV3Y6KE4PAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZVGAYDC>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Currently pacific time. We don't do dst here in Arizona. |
Beta Was this translation helpful? Give feedback.
-
|
Ya I know! It’s the worst. Just moved from the South bay in LA. Lord I miss it, had to come back East to take care of mom.
Not having much experience with GitHub is the best way to communicate, or is there a chat system build into their desktop? Haven’t had a chance to look.
From: Derrick ***@***.***>
Sent: Saturday, April 20, 2024 5:21 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
Currently pacific time. We don't do dst here in Arizona.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNJXWZW2XPAP7EB5OUTY6LL4HAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZWGM3TE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
My changes to the S90rgpio_pins.sh script updates. Has passed on both the Cerbo and RPi, 3 & 4’s. Next is to test the RPi with the Waveshare (non-FD) variant and see if it flies.
Need to order up a FD Hat and make sure that works as well.
It’s just a suggestion, how to deal with the issue. I made a call to new subroutine get_platform_setting that just reads Fredricks packageManager/Platform value and parses it for the 3rd literal. Kicks back PI for both the Pi3 and 4 variants. The I go to town, dealing with the changes needed to get it running on the PI, with some case statements.
Am I using that term correctly “literal”? Been more than a couple decades, since computer science programming classes. 😊 It just came out, when typing.
I’ll try to get it on GitHub for you guys to have a look, don’t laugh 😊 I’m a hardware engineer. As you both know, most hardware isn’t worth the sand it was made from without your skills. God bless you both.
Happy Sunday.
From: Derrick ***@***.***>
Sent: Saturday, April 20, 2024 5:21 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
Currently pacific time. We don't do dst here in Arizona.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNJXWZW2XPAP7EB5OUTY6LL4HAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZWGM3TE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Hello Guys sorry for the radio silence, I had to travel back to back for couple past weeks. Now I need to digest the 9 hours jet lag.. Regarding the Latency setting: I think it's fine we can remove this setting. That setting was a dirty workaround we make some optimisation... For Numbering the Digital Inputs and also the relays: Given the various platforms (rPI, Ekrano, Cerbo) that has from 0 unto 4 DI and Zero or 2 Relays, we need to discuss if we always want to have no discontinuity with the numbering (will require some more work ) or if RemoteGPIO will always start with the same numbering regardless of host platform. I propose we discuss this particular point in a separate discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Craig's changes are not yet incorporated. I propose we look at finishing the enhancements made in the dev branch, and then Craig should issue a PR with the pi changes. |
Beta Was this translation helpful? Give feedback.
-
|
OK then will test package name:RemoteGPIO username:drtinaz branch:dev |
Beta Was this translation helpful? Give feedback.
-
|
Oh yes, been mulling over that very topic since I started. I can’t think of a solution.
Didn’t really dig into it just because I know you said you had them all hard coded. Love to bounce ideas off and see if we can come up with something really slick.
From: Lucifer06 ***@***.***>
Sent: Sunday, April 21, 2024 12:34 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
Hello Guys sorry for the radio silence I had to travel back to back for couple past week. Now I need to digest 9 hours jet lag..
Hope to be able to test validate all the changes you guys have made.
Are Craig's changes for rPi support already in Derrick's dev distribution?
Regarding the Latency setting: I think it's fine we can remove this setting. That setting was a dirty workaround we make some optimisation...
For Numbering the Digital Inputs and also the relays: Given the various platforms (rPI, Ekrano, Cerbo) that has from 0 unto 4 DI and Zero or 2 Relays, we need to discuss if we always want to have no discontinuity with the numbering (will require some more work ) or if RemoteGPIO will always start with the same numbering regardless of host platform. I propose we discuss this particular point in a separate discussion.
—
Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNLD3WXBJXYJGYIYZJTY6PS6BAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCOBQGA4DI>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
What’s a PR? Pull request, I’m learning 😊
From: Derrick ***@***.***>
Sent: Sunday, April 21, 2024 12:39 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
Craig's changes are not yet incorporated. I propose we look at finishing the enhancements made in the dev branch, and then Craig should issue a PR with the pi changes.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNM7GCSW63XEZBY33ALY6PTT3AVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCOBQGEYTI>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
If you haven't already, create a fork of Frederic's RemoteGPIO (main branch as main) and then on your GitHub you can make and test updates/revisions. Once you have verified all is good then you can create a PR back the the upstream main. |
Beta Was this translation helpful? Give feedback.
-
|
@drtinaz I'm testing v3.2.17dev I like the idea of the sub-menu with additional options and good idea to remind about Addr setting depending of Unit# |
Beta Was this translation helpful? Give feedback.
-
|
I just tried the dtrinaz/dev branch and commented out the gui restart line in the S90 script and ran it manually. The relay overview refreshed properly without a gui restart. This test was without any actual relay boxes attached. The current state fields went to ?? briefly but came back within a couple of seconds. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: the GUI restart code in s90 will not work with RPI at the moment. RPI is still using /service/gui for the GUI, not service/start-gui like is used on other platforms. This will eventually change (probably) when Victron implements gui-v2 on RPI. There's code in PackagManager (towards the end) that you can look at so you can restart the correct service. |
Beta Was this translation helpful? Give feedback.
-
|
Try toggling the button to disable/enable RemoteGPIO from the settings menu? I got the blank relay overview on both my test system and production systems. Also try changing the number of relays for the module? |
Beta Was this translation helpful? Give feedback.
-
|
GuiMods v10.22 should fix the Relay Overview refresh issues. It rebuilds the relay list whenever the number of relays reported by systemCalc changes or when any of the show/hide relays change. So changing the number of relays per module or the number of modules will rebuild the relay list shown on the Relay Overview. I don't think you need to restart the GUI when running the S90 script. |
Beta Was this translation helpful? Give feedback.
-
|
Ok I will take it out. |
Beta Was this translation helpful? Give feedback.
-
|
Reconfiguring to zero for setup results in having to reset number of units after any package update as well as Venus os firmware update, which is why I removed it. If a user has auto install enabled in package manager and there is an update this would result in RemoteGPIO needing to be reconfigured before the relay modules will function again.This makes for a more seamless update. The gui Auto restarts anytime S90rgpio_pins.sh is ran. Without this, if the gui is on the relay overview page when S90 rgpio is ran it results in a blank overview page which can only be fixed by navigating to the settings page and then back to the overview page. S90rgpio is only ran at system reboot or package install (other than a manual restart in the settings menu). I think this is a fair tradeoff. What do you think? Venus reboot is not required because you already had the package installed and configured. A fresh install or uninstall will still reboot Venus automatically. You are correct, only the server needs to be set to rtu over TCP so that language can be changed. |
Beta Was this translation helpful? Give feedback.
-
|
Just finding some time to get back on this.
Derrick, just about to test again to see if I’m not crazy. Starting on line 82 of the S90, where you set all the DI’s types to 0. Could have sworn this removed all my DI from the Device List. Don’t recall every testing this on my GX. But I know on my latest running version I’ve got them all commented out on the RPI case.
Testing this right after I send this.
Then I’m off to figure out how to fork your project and publish it 😊
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 9:22 AM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
@Lucifer06<https://github.com/Lucifer06> v3.2.19dev just released. This one removes gui restart from S90 script. @kwindrem<https://github.com/kwindrem> has resolved the blank relay overview page issue from within guimods.
—
Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNPFBLM7WFURNU6PTCTY6ZOAVAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBRGA4DC>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Confirmed. Reboot of the RPI with those line uncommented, DI’s gone from Device List.
I’ve just included screenshots of Device List before and after and a shot of the S90 lines commented and uncommented. Need to try it next on the Cerbo.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 9:22 AM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
@Lucifer06<https://github.com/Lucifer06> v3.2.19dev just released. This one removes gui restart from S90 script. @kwindrem<https://github.com/kwindrem> has resolved the blank relay overview page issue from within guimods.
—
Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNPFBLM7WFURNU6PTCTY6ZOAVAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBRGA4DC>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
@cbelcher give me a few minutes, I want to make a few changes. I see no reason for the inputs to be set to disabled in the settings when there is a configuration change. The settings should always survive no matter what. Simply removing the digital input links should be enough to remove them from the device list when there is a configuration change. I don't want the user to have to reconfigure the digital inputs any time there is a configuration change or an update. Stay tuned, update coming momentarily. |
Beta Was this translation helpful? Give feedback.
-
|
Take your time.
Just kind of makes what little sense I have; if you yank its Type value it goes away? And it does, just commented them out again and the DI’s survive a reboot.
Going to test on the GX, they must behave differently, or this would be on your radar.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 1:28 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
@cbelcher<https://github.com/cbelcher> give me a few minutes, I want to make a few changes. I see no reason for the inputs to be set to disabled in the settings when there is a configuration change. The settings should always survive no matter what. Simply removing the digital input links should be enough to remove them from the device list when there is a configuration change. I don't want the user to have to reconfigure the digital inputs any time there is a configuration change or an update.
Stay tuned, update coming momentarily.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNPDLE7BJ3UKUM4S273Y62K2PAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBTHAYTG>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
It will act the same on the gx. I missed it because I am not using the gx to read inputs. v3.2.21dev just released and should fix this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Too cool.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 1:42 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
It will act the same on the gx. I missed it because I am not using the gx to read inputs.
v3.2.21dev just released and should fix this issue.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNIZV4WV3KKQHSZ4MELY62MPTAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBTHEZTA>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
I do not have a pi to test on so your feedback is appreciated. Do the digital inputs work as expected on your pi with the last update? |
Beta Was this translation helpful? Give feedback.
-
|
Pulling Repo as I type.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 1:51 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
I do not have a pi to test on so your feedback is appreciated. Do the digital inputs work as expected on your pi with the last update?
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNL6ANK4E3NB5FM5ODTY62NQ3AVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGAYTE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
We are talking the main branch, still just see 3.2.2.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 1:51 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
I do not have a pi to test on so your feedback is appreciated. Do the digital inputs work as expected on your pi with the last update?
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNL6ANK4E3NB5FM5ODTY62NQ3AVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGAYTE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
No. This discussion thread is for the dev branch. If you want to try the dev package you will need to uninstall and remove the current package from package manager and add the dev package using the inactive packages menu. There are many changes and enhancements to the dev branch |
Beta Was this translation helpful? Give feedback.
-
|
Do I need rights to this branch? From GitHub Desktop the only branches visible to me are: main & origin/old.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 2:07 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
No. This discussion thread is for the dev branch.
packagename:RemoteGPIO
username:drtinaz
branch:dev
If you want to try the dev package you will need to uninstall and remove the current package from package manager and add the dev package using the inactive packages menu.
There are many changes and enhancements to the dev branch
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNIZWL4I6OEKXZU7OL3Y62PN5AVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGE2DG>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
It sounds like you are on Frederic's GitHub. You will not find it there. It is on my GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
This is a shot of my GitHub Desktop? Let’s see if look different in web browser of your project.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 2:14 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
It sounds like you are on Frederic's GitHub. You will not find it there. It is on my GitHub.
https://github.com/drtinaz/RemoteGPIO/tree/dev
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNK3KFOQIPSL4452673Y62QGDAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGE4TE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Slight naming difference with 2nd branch, but close enough.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 2:14 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
It sounds like you are on Frederic's GitHub. You will not find it there. It is on my GitHub.
https://github.com/drtinaz/RemoteGPIO/tree/dev
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNK3KFOQIPSL4452673Y62QGDAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGE4TE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
@cbelcher if you are posting images I am not seeing any of them. You might try responding directly on GitHub instead of thru your email. |
Beta Was this translation helpful? Give feedback.
-
|
Roger that.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 2:23 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
@cbelcher<https://github.com/cbelcher> if you are posting images I am not seeing any of them. You might try responding directly on GitHub instead of thru your email.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNJL5ZZW3QDTKCAE3Q3Y62RGRAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGI3DM>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Let's see if you get my images from here. From GitHub website like so: What am I doing wrong? |
Beta Was this translation helpful? Give feedback.
-
|
You are on Frederic's GitHub. The dev branch is on my GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
You are correct. Your link took me to your fork. Thanks man!
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 2:31 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
You are on Frederic's GitHub. The dev branch is on my GitHub.
https://github.com/drtinaz/RemoteGPIO/tree/dev
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNMI5KR3DUWONF26H3LY62SGFAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGM2TE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Derrick, thanks for setting me straight. Off to testing.
From: Derrick ***@***.***>
Sent: Tuesday, April 23, 2024 2:31 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
You are on Frederic's GitHub. The dev branch is on my GitHub.
https://github.com/drtinaz/RemoteGPIO/tree/dev
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNMI5KR3DUWONF26H3LY62SGFAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBUGM2TE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
I'm now after your last v3.2.21dev release. You have done a great job in S90rgpio_pins.sh !!! I may start pulling all the changes on the main RemoteGPIO :-) |
Beta Was this translation helpful? Give feedback.
-
|
Undoubtably a race condition. RS485 will probably be slower than TCP. I haven't looked at the code but I would guess that the reading of the external relay state is happening in a separate thread than the sending of the GX state to the external relay. There may also be a delay in the external box reporting the changed state. You would need delay reading the external relay state after you set a relay state from the GX device. |
Beta Was this translation helpful? Give feedback.
-
|
Actually this is indeed managed in two separate services. It may require to sync each other. |
Beta Was this translation helpful? Give feedback.
-
|
Found it, PackageManager.py. Too cool, I can only imagine the number of hours Kev’s put into this. Incredible.
From: Lucifer06 ***@***.***>
Sent: Wednesday, April 24, 2024 1:47 PM
To: Lucifer06/RemoteGPIO ***@***.***>
Cc: Craig Belcher ***@***.***>; Mention ***@***.***>
Subject: Re: [Lucifer06/RemoteGPIO] RemoteGPIO enhancements (Discussion #31)
Actually this is indeed managed in two separate services. It may require to sync each other.
—
Reply to this email directly, view it on GitHub<#31 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABB7DNJMAIFKG3VJRURWXCLY67V2FAVCNFSM6AAAAABGNNVMPGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMJWGY3DO>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I didn't realize I was replying to your announcement when I should have started a new thread. Anyways, here goes.
Hello Frederic. Since you went through the effort to open this discussion board I thought I might as well start using it. This regarding our previous discussion concerning high system resources usage and possible freeze-up and reboot when using three modules.
I have made pretty good progress in my limited time testing. I have been able to reduce the overall CPU usage by 65 - 70% by making a few changes to the service and driver. I am going to continue testing. I would also like to make a few changes to the RemoteGPIO settings menus such as adding the ability to enable/disable reading external relay state and digital inputs for each module individually. I would also like to add a menu option to restart the rgpio service from within the menu for the following reason. I removed the dynamic updating of number of units and number of relays from the service loop as this was the highest usage of overall CPU usage and system resources, and added a one liner to run S90rgpio_pins.sh at startup before the loop. This alone results in a 50% reduction in system resource usage. I have tested this to work properly upon system reboot and firmware upgrade. What do you think? I don't want to spend a lot of time on changing/adding menu options if you are not in agreement.
Beta Was this translation helpful? Give feedback.
All reactions