-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Multiple Generators Monitoring #260
Comments
Let me think on this as there are some design trade offs to consider. My initial thoughts are that is is probably possibly to do this with a few changes to the code by running multiple instances of genmon on one system using the existing serial over TCP support, however making the UI respond to this would require some tweaking of the configuration files and java script to support multiple generators. I will get back to you once I have thought about this in more detail. |
I started working on this feature yesterday. I still have a lot of testing to do and there is at least one technical issue I have yet to resolve. There is a workaround for the one tech issue, but I am still trying to resolve this issue another way. This has to do with the way the software is restarted once am update to the software occurs. The workaround involves a custom script to restart all instances of genmon running. The caveat to this workaround is that if the software were updated from the web interface it would update all of the instances however you would need to restart all of the instances with a custom script instead of the web interface restarting it for you. |
I have updated the software to support this feature. This page describes what is needed to setup multiple instances of genmon on one system. https://github.com/jgyates/genmon/wiki/Appendix-J-Multiple-Instances-of-Genmon |
Sorry I've not responded sooner! busy week and I didn't notice the emails. This is fantastic progress for such a short time! So in this case I would be running entirely separate instances of the software, each having two unique ports, one for web UI and one for TCP-serial? I think the ideal arrangement would be more in depth than you may wish to pursue, and would be multiple back end TCP serial "listeners" each with their own port assignments all and feeding data into a single web service with a somewhat redesigned web UI that aggregates all the info and shares some settings across the board (such as system name, username/passwords for login, email notifications, ), while leaving other settings specific to the particular generator, (such as generator name, nominal voltage, fuel tank size, etc). and having some kind of menu to bring up each generator's information. If the instances can't easily be aggregated into a single web UI, Would it be possible to build a little landing page on port 80 that auto-populates with links to the different instances that are installed, just so the end user doesn't have to manually type a port number to get to the system or to the right generator? My goal would be to go to our server at http://genmonserver.localdomain/ and be able to click my way through to all the generators that the server monitors, even if the links open up new tabs going to the different generators' web pages. Another, more distributed model could be that there is an entirely separate piece of software that pulls data from multiple genmon devices on the field and simply packs it all onto one screen. This would require that there still be a raspberry pi at each generator, but it does solve the single pane of glass issue. At any rate, thanks so much for your help, and I look forward to seeing what you come up with! |
You will need TCP three ports per instance (web interface, serial over TCP, and the internal port used to communicate with add on apps). Regarding a unified web interface, yes this is possible, I would need to consider if this is worth implementing as well as the think about the best approach if implemented. |
I've been mulling this over and keep thinking of ideas.. haha A distributed model might be even better, and save you from reinventing the wheel. It could be that there is an entirely separate piece of "server" software that pulls data from multiple genmon devices In the field and packs it all onto one screen. This would require that there still be a raspberry pi running genmon at each generator, but it does solve the single pane of glass issue. This option could look a lot like many IP cameras systems I've seen, where the camera itself has a built in web UI that can be used by itself and has all the basic functionality to view the device, change its settings, and see its status (which is what you've already built in the genmon package running on the PI). This model would be more reliable, since a web API would be a more stable and reliable communication method than TCP serial when traversing the internet or slow/unstable connections such as backwoods cellular or unlicensed wireless links. Because the "server" would run on more capable hardware, It would be easier to add functionality such as detailed historical data, a map of all the generators with a weather overlay, integrations with other services, etc. Also, because the server presumably sits in a central office, It will provide a better page load time than a remote device hosting a web server. The server could also potentially be the better source of email alerting, because it can notify the user if it loses connectivity with a generator, preventing the situation where a monitor dies and simply goes silent, and the user is unaware of the next power outage or missing alert. What you've built so far has a great use case even within this model. If there were more than one generator at a single site, such as on a campus or large building (we have a few like this), they could all be connected to a single local piece of hardware, with each instance being "adopted" the same way that multiple devices would be. |
Not related to the request per-se but @jgyates I noticed duplicated content on the wiki regarding this (Appendix 10 and Appendix J) https://github.com/jgyates/genmon/wiki/Appendix-10-Multiple-Instances-of-Genmon and https://github.com/jgyates/genmon/wiki/Appendix-J-Multiple-Instances-of-Genmon |
Thanks, I removed the duplicate. |
I tried to add a multiple instance to my setup and 2 things:
|
Yes, the -c is required. I updated the wiki to reflect this. I also corrected the problem in startgenmon.sh that did not pass the command line parameter to genloader.py. Thanks for the feedback! Let me know if this does not correct the problem. |
Well I think my SD card is corrupted or something. Now when I run sudo bash startgenmon.sh start, it keeps looping and starting multiple python instances until the system locks up resources. Now I am using WinSCP to try and recover all of my configuration files to redo the SD card. I will let you know if I see any issues with a fresssh start. |
I am tracking the feature request list here: https://github.com/jgyates/genmon/blob/master/feature_requests.md I will be closing this thread for now but the request is still on the master request list. |
NOTE: A feature has been added in the upcoming release (V1.15.11) that affects running multiple instances of genmon. To run multiple instances of genmon (or any add on) you must set the multi-instance setting to True in the genmon.conf file, otherwise loading multiple instances will fail. More details are here: https://github.com/jgyates/genmon/wiki/Appendix-J-Multiple-Instances-of-Genmon |
Hi there, I have an idea for an enhancement to this project that would be of great use to us as a local municipal power, water, and gas utility as well as anyone monitoring multiple remote sites.
Would it be possible to add the ability to specify multiple generators to monitor over TCP Serial?
They could each have their own tabs in the web UI, or a combined view, and all alerts would originate from the same box.
We currently have two Genmon units installed as a pilot test of your solution, and they are working fantastically better than the Generac cellular solution.
Our use case would be to run the software on a virtual machine in our datacenter, and have it talk to several (10-20) TCP Serial targets which are generators connected to our private network at field sites such as tower sites, water tanks, electric substations, etc. to which we have either fiber or microwave IP connectivity. That way we aren't maintaining raspberry pi hardware in the field, we aren't paying for Generac cell modems at locations where we already have our own connectivity, and we have a single pane of glass to manage them all.
I'd suppose that a service company maintaining fuel levels, or a dealer who services these generators would also benefit from this functionality.
Either way, we appreciate your making this software open source. It has helped us to improve our quality of service to the utility customers we serve.
Thanks, and I hope this one sounds worth doing!
The text was updated successfully, but these errors were encountered: