On 2020/03/21 at 11:05 PM, pierre. said:

@Gnome  Does FastCGI somehow make it more robust? I'm thinking of using your inner C code in a Ruby gem, so that part would be a C extension in the gem.  Any thoughts?

So let me detail my thoughts on why I did things specific ways:

1) Why C?

• C library for HID and Serial port are the most mature libraries around.  Part of the reason so many of the other Axpert solutions are so unreliable with communication comes down to these libraries.  WatchPower uses their own USB library and RXTX (old and no longer used by most people) Serial Port library.  I tested a lot with both Ruby & Java libraries and all of them could get into unstable states or throw exceptions you don't expect.  Additionally the libraries for both Ruby & Java are not really maintained anymore.  They have bad performance and in most cases make use of a native library anyway.  The only cases that didn't make us of native (Ruby FFI based libraries and Java JNA based) were written by people that couldn't care about testing.

2) Why FastCGI?

• C language is not great for parsing input and writing output.  It requires 10x as much code to write in C as in Java.  FastCGI means I can let a mature web-server take care of that for me.  FastCGI is a long lived C process which is called every time the web-server receives data for that specific URL.  It is blazingly fast and lightweight.  In fact most routers still make use of FastCGI because it is fast enough to run on slow hardware and they don't need to re-invent the wheel of writing their own web-server.  Basically all web-servers support FastCGI.
• FastCGI also allows detaching the actual Voltronic communication protocol from the front-end component (web-server).  That means if the Voltronic fast-cgi library I wrote receives problems like failure to communicate or errors, it kills itself.  The web-server will then restart that process.  This means any bad state is lost.  The restart of the fast-cgi process makes no difference to performance while testing on a Raspberry Pi.  It just made it so that if you had a communication problem, it would clear itself up very quickly.  Don't get me wrong.  This almost never happens.  I had to purposefully pull the cable and things like that to simulate these problems.
• It is super fast.  During my testing the library gets as close to the raw speed that the Voltronic inverter can respond.  It isn't going to get much better than that.  Using a web-server that is mature means you get the fastest possible solution that uses the least amount of memory.  Nginx for example is designed to run with as little resources as possible.  Therefore by combing nginx and FastCGI you get the fastest possible way to communicate with your Voltronic inverter.
• You don't actually need to restart the FastCGI process because the C library handles the problems like a champ, but I did it because it is more predictable when distributing a library!

3) Can I just wrap the C library?

• Definitely.  You don't need to use FastCGI.  Use whatever you are comfortable with.  The FastCGI is just a wrapper around the Voltronic code.  You can probably use it as a guide for how to make use of the Voltronic library.
• This is about you and what you want.  The idea is to enable.  Nothing you suggest is a bad idea because it is exactly what you need.

4) What operating systems can this run on?

• I tested on Mac OSX, Raspberry Pi Buster, Ubuntu Linux x86-64, Amazon Linux, FreeBSD, Windows XP & 7.  In all cases I used both Serial and USB and it worked just the same on all of them.
• Most of your pain will be getting the C code to build on those operating systems but I've detailed how I did mine on my README file
• If you do build this for other platforms, please let me know because I'm very curious if you have any concerns or tell me about your wins!

5) Are there any outstanding bugs?

• Not at this time.  I've tested extensively with both USB & Serial and at this point I can't actually get it to miss behave.  Even when I pull the communication cable while it is busy running. It'll just restart the FastCGI process and continue on like nothing happens.
• If you encounter any, private message me, email me or create a ticket on the GITHUB page.  I'm happy to test more and get all those bugs sorted!

Edited March 23, 20206 yr by Gnome

Also I appreciate any feedback you have if you do end up using it!

On 2020/03/19 at 9:59 PM, SolarNoob said:

This looks very promising for relaying and updating setting on the voltronic inverters:

https://github.com/ned-kelly/docker-voltronic-homeassistant

This uses mqtt topics to send the info to home assistant. I just need to find a way to get the PylonTech BMS info sent via mqtt to my home assistant.  Home assistant then allows you to build rules relating to time of day and state of charge.

 

By remotely setting values via MQTT you can implement many more complex forms of automation (triggered from Home Assistant) such as:

• Changing the power mode to 'solar only' during the day, but then change back to 'grid mode charging' for your AGM or VLRA batteries in the evenings, but if it's raining (based on data from your weather station), set the charge mode to PCP02 (Charge based on 'Solar and Utility') so that the following day there's plenty of juice in your batteries...

• Programatically set the charge & float voltages based on additional sensors (such as a Zigbee Temperature Sensor, or a DHT-22 + ESP8266) - This way if your battery box is too hot/cold you can dynamically adjust the voltage so that the batteries are not damaged...

• Dynamically adjust the inverter's "solar power balance" and other configuration options to ensure that you get the most "bang for your buck" out of your setup...

Haha, man I played with this the whole weekend.

I haven't looked at their C code too hard, but their whole deal is to make use of Docker to guarantee it'll work on any platform.

You will however need to compile it for your own platform because the C code needs to be built for you CPU.

Thank you so much for posting this.

Although they have a lot more on offer than I do, I think my low level library is significantly more robust and mature than theirs.  So I'll continue to use my library and instead make use of the frontend ideas to push out more. (Of course I'm biased, so no need to point this out! 😛 ).  I think overall, the biggest problem with their approach is the lack of how to make it work

This weekend I was able to create a docker container using my own code that will run on any operating system and I just basically was able to do the same as them.

My only concern is, most people really struggle with things like Docker and I would love for a more seamless experience.  But 1 thing at a time.

Edited March 23, 20206 yr by Gnome

13 minutes ago, Gnome said:

RXTX

Oh bloddy hell... I remember that monstrosity. They changed namespace from javax.comm to gnu.io at some point, causing a whole heap of old stuff to stop working. The only way I could make it work was a search and replace hack job and a recompile. I'm not even a Java guy.

Edit: Oh wow... I was nice enough to put it back on github.

Edited March 23, 20206 yr by plonkster

9 minutes ago, plonkster said:

Oh bloddy hell... I remember that monstrosity. They changed namespace from javax.comm to gnu.io at some point, causing a whole heap of old stuff to stop working. The only way I could make it work was a search and replace hack job and a recompile. I'm not even a Java guy.

Indeed, it is a very clunky library.  They also make use of a native library underneath and communicate with that using JNI (Java Native Interface).  Basically it is a C library with Java bindings.  The problem with that sort of library is, it doesn't adhere to the Java way of compile once, run everywhere.  You need to compile that library for every single operating system and processor combination.

WatchPower gets around this by including the compiled C library with the ZIP file for the specific operating system.  It makes me die a bit inside when I see people doing that.

Serial port libraries written in C are only calling the operating system C code.  For Windows it is calling the Windows functions (kernel32.dll functions), and on Posix (Mac/Linux/FreeBSD/etc.) it is calling Lib C functions.

The most modern approach to this problem is to use something called FFI (Foreign Function Interface). FFI allows you to call C libraries like Kernel32.dll and Lib C straight from your code in Java, Ruby, Python, etc.  It'll then run anywhere without you needing to build a C library for that operating system.

There are some attempts at it, but most of them are half baked hack jobs and frankly I understand why.  It takes time.  It isn't like it takes more time than writing the C library, it takes the same amount of time, but nobody really wants to do it because other solutions exist.

I did for some time attempt to translate the C libraries I'm using into FFI with both Ruby and Java but it is a lot of code to translate.  And frankly it isn't even solving a problem I care to solve.  That is something for future me to tackle when I'm bored.

/Rant

Edited March 23, 20206 yr by Gnome

14 minutes ago, Gnome said:

Indeed, it is a very clunky library.  They also make use of a native library underneath and communicate with that using JNI (Java Native Interface).  Basically it is a C library with Java bindings.  The problem with that sort of library is, it doesn't adhere to the Java way of compile once, run everywhere.  You need to compile that library for every single operating system and processor combination.

True, but that's a problem for almost all languages. At some point it meets the hardware and some kind of interface is necessary. When it comes to that point, what matters is how easy the designers made it to write extensions. That's one thing I love about python: That it is relatively easy to make extensions, and there are multiple ways of doing it too, ctypes being one of the lowest impact ones. Still, that has the same problem then: It needs that extension to be compiled for every platform it is going to run on. So people make pure python extensions (eg compare the reference python-dbus library, which wraps the native dbus libraries, with txdbus which is pure python), and these are of varying quality, as you might expect.

Some of this nonsense I actually blame on the way the Axpert people made their serial port work. Why HID? Why not good old serial comms like everyone else out there? Then you could use the existing serial capabilities on almost every OS and just have it work...

1 minute ago, plonkster said:

Why HID? Why not good old serial comms like everyone else out there? Then you could use the existing serial capabilities on almost every OS and just have it work...

Drivers.  Serial ports require drivers to translate USB -> serial.  HID is natively supported in the USB specification so every operating system supports it as is.  All the operating systems also already provide a native way to interface with them (kernel32, IOKit for OSX and HIDRaw for Linux).  There is only really one USB -> Serial adapter that is reliable IMO, Prolific chip based.  A lot of clones copying their chips have made the rounds because their chip is just the best.  It is also affordable and the driver support every operating system.

So Voltronic probably didn't want to copy the Prolific chip or pay for it and their chip isn't cheap.

In that way I do get why they did it.

53 minutes ago, Gnome said:

Prolific chip based

Have had more trouble with PL230x chips than the FTDis. But the FTDi is even more expensive... and has way crappier clones. Plus, FTDi actually bricked chips, which was a tad nasty. Still, prefer an original FTDi over others.

.

Edited July 13, 20205 yr by pierre.

Hi, 

I posted this a while back but got no response, I'm hoping someone here can help me. I'm wanting to be able to switch on the inverter using the settings menu remotely. 

I use the QPIGS command from Python to monitor my Mecer (Axpert) 3kVA 24V inverter from a Raspberry Pi. Currently I leave it in SENS mode in the settings so that it only fully turns on the inverter when a load is detected. If the load is over about 100W then this works fine and it turns on, however anything less than this and it won't turn on.

If I want to turn it on for a lighter load I can change the setting from SENS to SDS (I think it's called) in setting 3 or 4 in the menu. I was hoping maybe I could use a command (QPIGS/QPIRI/QFLAG or something) in Python. Anyone know what command I need to send the inverter?

Thanks.

37 minutes ago, Lindsay said:

If I want to turn it on for a lighter load I can change the setting from SENS to SDS (I think it's called) in setting 3 or 4 in the menu. I was hoping maybe I could use a command (QPIGS/QPIRI/QFLAG or something) in Python. Anyone know what command I need to send the inverter?

Try PEj and PDj to enable and disable power saving respectively. So that's three letters, first two must be upper case as with most commands, but the last letter, the 'j', must be lower case.

Hi Coulomb,

That seemed to work, I replaced QPIGS for PEj or PDj in my script and didn't bother reading any feedback.

However my initial script accidentally had an infinite loop, which caused it to send the command to switch on (power saving off) the inverter over and over. I stopped the script, fixed it, ran a script to turn off the inverter (power saving on) and it seemed to work, however a few minutes later the inverter had turned on again. I then ran "sudo pkill -f <script name>" and also ran my script to turn off the inverter yet again but it still seemed to turn itself on again after a few minutes of power saving.

When I "sudo ps ax | grep python" I saw my script to switch on the inverter still listed, so I'm not sure if it's actually then still running? 

This was last night and this morning I found the inverter running again and I manually switched it off using the control panel/settings directly on the unit. A few minutes later it did a lot of relay clicking, the voltages shot up to 32V and then settled back to 28.5V and a few minutes after this the inverter turned back on yet again.

So maybe my script is still running and looping? I guess the only way to really stop my script running might be to reboot my Raspberry Pi?

 

 

 

On 2020/10/30 at 1:37 PM, Lindsay said:

So maybe my script is still running and looping? I guess the only way to really stop my script running might be to reboot my Raspberry Pi?

It worked 100% after I rebooted, 😃 stays off after I switch it off.