| Back to Moixa Battery Index | http://graham.auld.me.uk | E-Mail me |
| GitHub - no project here yet |
ok, what fun can we have?
The rediculous bright backlit LCD just to show the Moixa logo annoys me. Obviously more practical use of the screen would be good but for now, can we just save the power and turn it off?
/usr/sbin/gui-display/moixa.jpg - that's the logo file that gets punted to the screen. The application /usr/sbin/gui-display/gui-display pops that on the screen at bootup. Once you've replaced or changed moixa.jpg just issue kill `pidof gui-display` the supervisor will relaunch the application and update the screen. Annoyingly though you'll notice colours don't render properly - more info on this later.
Something mildly more useful that the logo - but not much. You can pop up the commissioning display - software version, hostname/MAC address, IP address, some basic functional status
/usr/sbin/gui-display --type commission -qws &We know thanks to the doc page that we're looking at an ads7846 touch screen controller. Looking with lsmod we can see the ads7846 touchscreen module is loaded - look in /dev/inputs and you'll find event0 and event1 - event1 is linked to the touchscreen, event0 is linked to the three physical buttons on the top of the screen
there's a minor annoyance, random button pushes /touches are registered from time to time and it's clearly not setup correctly as there's no touch input when you try and use it. Disable the touchscreen for the moment with rmmod ads7846
Ah, that remote GUI thing you get on the web - I'm sure that must go on the display - it does on a normal GX device...
Well, /opt/victronenergy/gui/gui -qws & - few catches -no working touchscreen interface, you'll notice the loading screen is out 90 degrees. Then when it loads you're out 180 degrees. I compiled a simple framebuffer application and established that the framebuffer drive is indeed - upside down. One of my units even suffers from phantom mouse/touch inputs from the touch screen so when you load it it starts to set random settings!
Firstly, we already have the gui running, we really want the same instance on the screen as we have on the VNC session. This is easy to deal with - the gui is started by the script /opt/victronenergy/gui/start-gui.sh - that looks for a file /etc/venus/headless - if it exists, you get vnc at 480x272 resolution, if it doesn't exist, you get the framebuffer resolution on the display and VNC. So, let's just rename that headless file mv /etc/venus/headless /etc/venus/notheadless then restart the gui service kill `pidof gui`
Ok, so it's upside down, the touch panel is useless, when you VNC to it it's 90 degrees out and the blocks don't render at a nice size... baby steps
When we reboot that pesky gui-display service that drives the Moixa logo overwrites the frame buffer - boo.
/service/gui-display a sofllink to /etc/moixa/gui-display/service - stop it loading with rm /service/gui-display - should you want it back then ln -s /etc/moixa/gui-display/service /service/gui-display
Although - a word of caution - when you do this, you'll just have nothing on the screen - if you removed /etc/venus/headless then you were expecting the Victron GUI to load but it doesn't... kill `pidof gui` will relaunch it and it will come to life.
What's happening here is another bit of sloppy system config - The system boots using initd scripts to runlevel 5 - the scripts in /etc/rc5.d are run in order - S95svscanboot.sh kicks off all the services which include the gui - S98lcd.sh loads the display driver (yes, afterwards) - now this probably works either because the gui-display that loads the Moixa logo is a bit slow or it has been coded to block for the framebuffer device - dunno, anyway, easy solve - load drivers before you start software... mv /etc/rc5.d/S98lcd.sh /etc/rc5.d/S03lcd.sh
Right, I'm fed up now, let's sort this bit. Here's how the frame buffer display driver is loaded in the stock firmware modprobe fbtft_device name=matrix-st7789s speed=28000000 bgr=1 verbose=3 debug=0 gpios=reset:203,cs:67,dc:1
There are two problems here, one, it's upside down, two they've not bothered to flag the backlight pin - what we want is more like modprobe fbtft_device name=matrix-st7789s speed=28000000 bgr=1 verbose=3 debug=0 rotate=270 gpios=reset:203,cs:67,dc:1,led:0 (on a live system you need to remove the module rmmod fbtft_device before you can issue that modprobe to add it with more helpful parameters)
This module loading is carried out by an init script during boot - specifically /etc/init.d/lcd.sh - edit that to add the rotate and LED parameters. With rotation fixed and backlight linked you now don't need to mess with GPIO to turn the backlight off echo 1 > /sys/bus/spi/devices/spi0.0/backlight/fb_st7789s/bl_power or on echo 0 > /sys/bus/spi/devices/spi0.0/backlight/fb_st7789s/bl_power
Now, why 270 not 180 rotation... well, when you rotate by 180 (or don't rotate) - the framebuffer fbset -fb /dev/fb0 claims to be 240x320 - if you rotate by 90 or 270 then you get 320x240. The default is a portrait resolution.
One more annoyance - the colour isn't quite right on the LCD - On VNC I can see AC Input is red, on the LCD it's blue. This looks like a fairly straightforward mix up between the red and blue channel. If you customised the Moixa logo at /usr/sbin/gui-display/moixa.jpg you probably noticed it's redish instead of blueish. Looks like the developers tripped over this little colour channel mix up on the LCD and 'fixed' it.
remember /etc/init.d/lcd.sh - one more tweak, we're going to set bgr=0 modprobe fbtft_device name=matrix-st7789s speed=28000000 bgr=0 verbose=3 debug=0 rotate=270 gpios=reset:203,cs:67,dc:1,led:0
bgr=1 swapped the colour bit order from Red Green Blue to Blue Green Red - why was that even swapped in the first place? My best guess - software developed to a budget...
The gui just renders things it finds on dbus (api) - Specifically though it runs based on things published in the com.victronenergy.system service. This data is generated by the Systemcalc service. We just need to make data available where dbus-systemcalc goes looking and then we're in business.
Adding PV Inverter data requires a com.victronenergy.pvinverter service - that service must publish as a minimum,/Ac/L1/Power and /Position. Power is just the power in watts - note if you provide L2 and L3 values they're all summed on the display. Position is 0 for /Ac/PvOnGrid, 1 for /Ac/PvOnOutput, 2 for /Ac/PvOnGenset. This then populates in the system service /Ac/PvOnGrid/L1/Power, the presense of which causes an orange box to turn up with the PV Inverter data.
The Grid metering is interesting, sort of - the stock Moixa setup has the grid box but it actually reports power in and out of the grid connection of the inverter/charger. If we provide a com.victronenergy.grid service publishing a minimum of /Ac/L1/Power (and again, you can do three phases) then that gets picked up and out on the system services at /Ac/grid/L1/Power and home consumption (grid + battery - inverter) gets published at /Ac/ConsumptionOnInput/L1/Power. The practical upshot is the GUI makes sense with the Grid box showing grid power in/out, AC Loads reporting your home consumption.
Practically I got this running with a modified version of my Modbus meter reading python code - it still generates the energy meter service but also now generates grid and pvinverter services to feed the display.
I need to do some quality checks before I release this one - I've run it on my battery though, looks about right but need it running in daytime to verify the solar numbers.
A quick note on services - nearly everything running in Venus OS runs as a service, if it dies, it gets restarted by a supervisor. If you want to control services, you need to be in the right directory cd /service and then you can stop a service like the gui with svc -d gui or start it with svc -u gui documentation on the svc command
You've probably not noticed, the processor module inside the Moixa Hub box has a red power LED and a green activity one. you can turn those off - or back on