See attached screenshots.
Pure Python, SQLite, jQuery, HTML and CSS; serves a web page and uses websockets for peppy performance and real time (1s update) monitoring. I don't get off on 'pretty', so it ain't nothing but functional. I don't have a Whiz Bang Jr yet, so the real time data is incomplete. Working on getting the communication protocol for my MagnaSine MS4448PAE to integrate it, too, but radio silence from Magnum Dimensions so far. If anyone has knowledge, I'd be most appreciative.
I'm not sharing it until I have more time on it and greater confidence of its stability and performance, but would like some input from the community. Also looking for information about the Combo Charge Stage register, specifically what is "state", i.e. the LSB? Register Map document indicates vaguely what each number means, but I'm curious about their definitions as my goal is to write a driver to control an OpenEVSE vehicle charge controller to keep the system at MPPT for as long as possible during the day without cooking anything, and "state" may be exactly what I want.
I'm doing a crude calculation of inverter efficiency by calculating PV power (P
pv=I
pvV
pv), but clearly don't have it right as the efficiency results occasionaly suggest a violation of physical laws. Again, any info from the more educated is appreciated.
Specifics:
- Orange Pi Zero with NAS board and 64GB MSATA storage to keep from pounding the SD card to an early death
- Armbian OS
- Poll Classic every minute via a Cron job to accrue history, which is stored on the MSATA card
- The entire collected history is available for plotting
- Real time data polling period is user-selected and clicking on the values in the schematic toggle plotting of selected field
- It's only a week old, so I'm still scoping features and debugging; will figure out plot zooming eventually and also saving real time data to the server
Is it going to work on a Raspberry Pi ?
I will be happy to give it a try when you release it . ( or test it out)
Yes the Whizbang additions are certainly needed since that has all the valuable battery and load data.
Also - will it be able to view two or more Classics in Follow Me ( or just two classics ?)
Larry
Mr. Chowderhead, here is an old document about Magnum's communications.
It is over 10 years old but I think the basic protocol is very similar.
This documentation used to be available on their web site.
Keep up the good work !
boB
@Larry:
I'm not clear on the Follow Me protocol, but this should communicate with every classic on the network having a unique IP address. I'll need to make some minor modifications to facilitate that. Give me a while, this is just one of many irons in the fire.
It will work on anything running a recent version of Linux AFAIK.
#boB:
That is a little nugget there! Thanks!
No hurry !
Yes that is all that would be needed is different IP .
Larry
@boB:
That document is still valid. I'm communicating with the MagnaSine! Thank you very much!
I haven't been here on midnight for a while now, and was interested to see what was happening.
Looking at the developments of chowderhead reminds me when I first started my own project, QuadlogSCADA, which started some years ago and with the help of some of the good folks here on MidNite Solar.
Not wanting to highjack the thread, but I would like to give some details on how my own project has progressed and maybe to give some ideas for chowderhead, if he wishes.
So, quitely in the background I have been progressing my project and has some similarities to this project.
To give a brief overview of it, if I could:
QuadlogSCADA is pure Python, using Python 3.7+ as it uses async routines.
The application is made up of two coupled programs, one as the IO Device scanner, using Modbus RTU or TCP to do the communications to devices, whether that be solar controllers or industrial PLCs.
The other application is the lean and mean web server based on Sanic, based on asyncio.
The two Python programs are connected together by using a high speed no SQL data store, Redis.
Redis is also used to store time series data which is logged by the IO Device scanner and is accessed by the Sanic application for giving data to the web application, which is a single page javascript application.
The web application is fast and being a single page application works as if it were a local application, no re-loading of HTML or anything else after initial load.
The web application uses web sockets for very low data bandwidth of data to keep the web application alive with at the moment data as acquired from the Modbus device.
The web app allows the user to log in securely and view and alter data as well as setpoint data and also view various logs and historical data in charts using 'Ploty.js'
The project is really a framework, where the design allows for fitting it in to various applications by users. It is 'Open Source'.
I initially started the project as an alternative to propriety SCADA applications that only worked on Microsoft Windows operating systems.
QuadlogSCADA was designed to run very well on GNU/Linux, and I use Debian.
The system is set up such that both the IO Device scanner and Web Server applications are brought up on system startup using systemd.
It has proved to be reliable I have now operating in an industrial control situation where it controls the whole show and using industrial based Arduino controllers.
I have been really happy with how well this has all worked, and now am in love with Python, having initially started the project using C/C++.
If anybody is interested in the code or the web app screen captures, I can pop them up here for ideas, maybe in a new thread of course.
Just a little quick screen capture of one my own solar system showing the LiFePO4 battery attached.
QuadlogSCADA is a cool name, Paul.
And excellent for the results, Chowderhead !
Good stuff !
boB
Thanks Bob,
When I was much younger and starting out in industrial control systems last century I was a trade show for such industry, and was very impress with a brand of industrial controller manufactured by Moore, the Moore APACS Quadlog system.
A link to their legacy system: https://www.classicautomation.com/Parts/moore-quadlog (https://www.classicautomation.com/Parts/moore-quadlog)
That name stuck in my thoughts ever since and I thought it had a nice 'something' about it, and so used it.
Also, there was a possibility that the quad part of it would describe four discrete components that made up what I was doing with it.
I like how chowderhead has done their charting, with selection to grab data.
I am almost at a stage where I am looking for like minded people who are interested to contribute to this open source project, and this might be one avenue, here on MidNite.
Need to setup my github better, some learning there yet.
Chowderhead, I think I did something here on MidNite forums some years back with the MagnaSine to decode the data stream. It was one of my first Python works, called MagPy, I think the story starts from here: http://midniteftp.com/forum/index.php?topic=2458.msg24089#msg24089 (http://midniteftp.com/forum/index.php?topic=2458.msg24089#msg24089) :)
It would be possible to integrate the code from MagPy into QuadlogSCADA or maybe even your own code.
From the first post in this string: "my goal is to write a driver to control an OpenEVSE vehicle charge controller to keep the system at MPPT for as long as possible during the day without cooking anything".
I sometimes control my OpenEvse car charger by increasing and decreasing the charge rate according to a derived differential voltage setpoint. The control reads the Classic state voltage setpoint and also the battery voltage. The battery voltage is subtracted from the state voltage setpoint. Example: Float voltage setpoint = 52.4 battery voltage = 52.3 differential voltage = .1. The control, using the openEVSE RAPI command system, increases the amps flowing to the charger if the differential is less than .2V. If the differential is greater than .2 V then it decreases load. So if one sets the Classic voltage setpoints at say .2V above the actual desired setpoint then the control reduces the battery voltage by diverting excess power to the car. This causes the Classic to maintain as much power output as possible as it never makes it to it's setpoint. Code attached. This is cut and pasted from a larger code section. I run my system based on HWT tank temperature and array output however the code for voltage diversion is included in this code. Not included is reading from the Classic or the differential voltage calculation. I have not run the reduced code attached however the commands to the OpenEvse increasing and decreasing load work very well.