diy solar

diy solar

Solar Assistant - data logger

And you're able to effect change using this:

And you get the "saved" message when changing the output in home assistant:

1662536195100.png

mqtt updating would not work for my setup until I successfully got the "saved" message here in home assistant.
The various Response errors were "unknown" and "Error: Updates not allowed".
Once I got rid of those errors, then the NR update worked.
 
One of the problems with the Home Assistant implementation is the saved message from the previous use of the dropdown is there already, so there is no visible indicator it has actually taken.
 
Is anyone else getting these errors in home assistant? The errors make no sense as the values in question are valid.

Logger: homeassistant.components.mqtt.select
Source: components/mqtt/select.py:167
Integration: MQTT (documentation, issues)
First occurred: September 7, 2022, 2:13:50 PM (411413 occurrences)
Last logged: 9:15:20 PM

  • Invalid option for select.inverter_1_to_grid_battery_voltage: '49.0' (valid options: [44.0, 45.0, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0, 55.0, 56.0, 57.0])
  • Invalid option for select.inverter_1_battery_float_charge_voltage: '54.6' (valid options: [48.0, 48.1, 48.2, 48.3, 48.4, 48.5, 48.6, 48.7, 48.8, 48.9, 49.0, 49.1, 49.2, 49.3, 49.4, 49.5, 49.6, 49.7, 49.8, 49.9, 50.0, 50.1, 50.2, 50.3, 50.4, 50.5, 50.6, 50.7, 50.8, 50.9, 51.0, 51.1, 51.2, 51.3, 51.4, 51.5, 51.6, 51.7, 51.8, 51.9, 52.0, 52.1, 52.2, 52.3, 52.4, 52.5, 52.6, 52.7, 52.8, 52.9, 53.0, 53.1, 53.2, 53.3, 53.4, 53.5, 53.6, 53.7, 53.8, 53.9, 54.0, 54.1, 54.2, 54.3, 54.4, 54.5, 54.6, 54.7, 54.8, 54.9, 55.0, 55.1, 55.2, 55.3, 55.4, 55.5, 55.6, 55.7, 55.8, 55.9, 56.0, 56.1, 56.2, 56.3, 56.4, 56.5, 56.6, 56.7, 56.8, 56.9, 57.0, 57.1, 57.2, 57.3, 57.4, 57.5, 57.6, 57.7, 57.8, 57.9, 58.0, 58.1, 58.2, 58.3, 58.4, 58.5, 58.6, 58.7, 58.8, 58.9, 59.0, 59.1, 59.2, 59.3, 59.4, 59.5, 59.6, 59.7, 59.8, 59.9, 60.0, 60.1, 60.2, 60.3, 60.4, 60.5, 60.6, 60.7, 60.8, 60.9, 61.0, 61.1, 61.2, 61.3, 61.4, 61.5, 61.6, 61.7, 61.8, 61.9, 62.0, 62.1, 62.2, 62.3, 62.4, 62.5, 62.6, 62.7, 62.8, 62.9, 63.0, 63.1, 63.2, 63.3, 63.4, 63.5, 63.6, 63.7, 63.8, 63.9, 64.0])
  • Invalid option for select.inverter_1_max_grid_charge_current: '60' (valid options: [2, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120])
  • Invalid option for select.inverter_1_shutdown_battery_voltage: '46.0' (valid options: [44.0, 44.1, 44.2, 44.3, 44.4, 44.5, 44.6, 44.7, 44.8, 44.9, 45.0, 45.1, 45.2, 45.3, 45.4, 45.5, 45.6, 45.7, 45.8, 45.9, 46.0, 46.1, 46.2, 46.3, 46.4, 46.5, 46.6, 46.7, 46.8, 46.9, 47.0, 47.1, 47.2, 47.3, 47.4, 47.5, 47.6, 47.7, 47.8, 47.9, 48.0, 48.1, 48.2, 48.3, 48.4, 48.5, 48.6, 48.7, 48.8, 48.9, 49.0, 49.1, 49.2, 49.3, 49.4, 49.5, 49.6, 49.7, 49.8, 49.9, 50.0, 50.1, 50.2, 50.3, 50.4, 50.5, 50.6, 50.7, 50.8, 50.9, 51.0, 51.1, 51.2, 51.3, 51.4, 51.5, 51.6, 51.7, 51.8, 51.9, 52.0, 52.1, 52.2, 52.3, 52.4, 52.5, 52.6, 52.7, 52.8, 52.9, 53.0, 53.1, 53.2, 53.3, 53.4, 53.5, 53.6, 53.7, 53.8, 53.9, 54.0])
  • Invalid option for select.inverter_1_back_to_battery_voltage: '54.0' (valid options: [0.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0, 55.0, 56.0, 57.0, 58.0, 59.0, 60.0, 61.0, 62.0, 63.0, 64.0])
 
$40 for this nonsense is ridiculous.
OK, I have to take that back.

Inside the box there was a second cable. It was hidden and nothing on the outside of the box to indicate it was there.

That extra cable has an RS RJ-12 (25?) jack on one end and the other end connects to the 9-pin RS-232 jack.

Plugged it in this morning to the RS-232 port of the top battery and the USB port of the Solar Assistant raspberry Pi and Solar Assistant immediately recognised the new connection and I now have my battery data showing:

Screen Shot 2022-09-21 at 6.30.29 am.png

I apologise to Jakiper, they did actually send me something which works.

Which is great. It's not the prettiest looking set up and I would like the two 9-pin connectors to be a little more securely attached to each other but hey, it works.

The downside however is with Solar Assistant I can't have this data AND my Victron smart shunt data. I have to choose one or the other. If I could have both I'd put the smart shunt on the Lead bank. It would then be (potentially) feasible to monitor the relative contributions.

For now I will choose to monitor the LiFePO4 batteries only as these are what do the daily cycling and represent the storage capacity within which I plan to operate and will have my automation set up for. The Lead is there for grid outage backup and pretty much just floats.

Edited connector type for clarity.
 
Last edited:
As far as I know all easun inverters are voltronic inverters, but looking at the easun downloads page I see watchpower is listed under most inverters, but not all of them:


View attachment 81220

If watchpower doesn't work with your inverter, then I doubt solar assistant, solpiplog, mpp solar, etc. will work.
On the developers page https://solar-assistant.io/help/installations/axpert-parallel-pylontech they say must solar pv1800 works with Solarmonitor
 
Here are the steps - please let me know if it works for you. This is all from memory and it's been a while so I may have missed a step. There are two prerequisites - (1) that you know how ssh keys work and how to generate and retrieve the public key you want to use to access the SA pi; (2) you know how to mount the SD card and modify its filesystem.

1. Mount the SD card with the solar assistant image on a Linux machine or something capable of read-write on ext4 file systems.
2. If you don't have an ssh key on your local machine, create one. Instructions vary by OS/ssh client but standard *nix systems you just run "ssh-keygen". Copy the contents of your public key.
3. Append the public key to /etc/updates.allow on the solar assistant image
4. Modify /etc/security/init.sh and comment out the following line by prefixing it with a '#':
if ! [[ $(cat /etc/updates.allow | wc -l) == 1 ]];then exit 1;fi
5. Put the SD card back into your Pi and boot it up.
6. ssh solar-assistant@<ip address of your pi> -p 2222 (tcp port 2222)

The code seems to be synced to the pi each time it starts up and is stored in shared memory so it's wiped on reboot. It's located in /dev/shm/grafana-sync. It's compiled Elixir code so you won't be able to do much with it. The influxdb data is located in /var/lib/influxdb and of course /var/log will have all the interesting log files. sudo also works password-less.
These steps work perfectly on my Solar Assistant Pi 1 B+. I use putty with a puttygen private key managed with pageant ;)
I'm gonna try setting up a cron job to rsync my influxdb data to a USB SSD drive daily!
 
I finally got around finishing a script for Solar Assistant to do hourly backups.

Requirements:
- USB stick, can be fat32 formatted for easy Windows read.
- Access to the Solar Assistant file system either via SSH or mounting the SD card on a linux machine

Add the following code into a file on /etc/cron.hourly/<filename>, I named mine sa_backup. Make sure the file is executable.

It will automatically make an hourly backup and save it on the USB drive. You can pull the stick pretty much any time and it will just skip the following backup until you put it back in. The backups seem to happen at the 17th minute of every hour on mine (you can verify by looking at your /etc/crontab file when the hourly call is made)

I also log the backup status to both ~solar-assistant/backup.log and the same file on the USB stick.

If you want to temporarily stop the backups, just place a nobackup file in solar-assistant's home directory by running touch ~solar-assistant/nobackup on the raspberry PI. I would put this file there before I went over to the device to pull the USB stick in case I would happen to be doing it at the 17 minute mark.

Bash:
#!/usr/bin/bash
cleanup_tasks() {
    if [ "$2" -lt "1" ]; then
        /usr/bin/echo "$timestamp SA Backup Completed - $1" >> /home/solar-assistant/backup.log
#        /usr/bin/find /mnt/usb/SA_Backup/* -type d -mindepth 1 -maxdepth 1 -mtime +30 -exec /usr/bin/rm -rf {} \;
    else
        /usr/bin/echo "$timestamp SA Backup Failed - $1" >> /home/solar-assistant/backup.log
    fi
    if [ "$2" -lt "2" ]; then
        /usr/bin/cp /home/solar-assistant/backup.log /mnt/usb/SA_Backup/backup.log > /dev/null 2>&1
    elif [ "$2" -eq "2" ]; then
        /usr/bin/cp /home/solar-assistant/backup.log /mnt/usb/solar_assistant_backup.log > /dev/null 2>&1
    fi
    cd /mnt
    /usr/bin/sleep 5
    /usr/bin/umount /mnt/usb > /dev/null 2>&1
    exit 0
}
timestamp=$(date +"%Y%m%d_%H%M")

if [ ! -f "/home/solar-assistant/nobackup" ]; then
    if [ ! -d "/mnt/usb" ]; then
        /usr/bin/mkdir /mnt/usb || cleanup_tasks "/mnt/usb creation failed" 3
        /usr/bin/chmod 755 /mnt/usb || cleanup_tasks "chmod /mnt/usb failed" 3
    fi
    /usr/bin/mount /dev/sda1 /mnt/usb > /dev/null 2>&1 || cleanup_tasks "Mount Failed" 3
    if [ ! -d "/mnt/usb/SA_Backup" ]; then
        /usr/bin/mkdir /mnt/usb/SA_Backup || cleanup_tasks "/mnt/usb/SA_Backup creation failed" 2
        /usr/bin/chmod 755 /mnt/usb/SA_Backup || cleanup_tasks "chmod /mnt/usb/SA_Backup failed" 2
    fi
    cd /mnt/usb/SA_Backup > /dev/null 2>&1 || cleanup_tasks "SA_Backup Directory Not Found" 2
    /usr/bin/influxd backup -portable /mnt/usb/SA_Backup/$timestamp/ > /dev/null 2>&1 || cleanup_task "InfluxDB Failed" 1
    /usr/bin/tar -czf /mnt/usb/SA_Backup/$timestamp/grafana_db.tar.gz -C /var/lib/grafana/ grafana.db || cleanup_task "grafana tar Faield" 1
    if [ -f "/home/solar-assistant/backup.tar.gz" ]; then
            /usr/bin/rm -f /home/solar-assistant/backup.tar.gz
    fi
    /usr/bin/tar -czf /home/solar-assistant/backup.tar.gz -C /mnt/usb/SA_Backup/$timestamp/ . || cleanup_task "package tar Failed" 1
    cleanup_tasks "Success" 0
else
    /usr/bin/echo "$timestamp Backup Skipped" >> /home/solar-assistant/nobackup
    /usr/bin/echo "$timestamp SA Backup Skipped" >> /home/solar-assistant/backup.log
fi
 
Last edited:
So just a quick update: it looks like the good folks at Solar Assistant tried to clamp down access in very interesting ways but in their work they made a critical mistake that also broke cron.

They tried to disable access with password or any other means besides their own private key. They obfuscated the allow list of keys, they make sure that sshd has login with password turned off and they also ensured that only one key is allowed in the file and it has to be their key. If you do anything "hokey" like adding another key, replacing the key, moving the source of the keys for sshd to another file or enabling passworded logins PAM will deny access.

BUT they also mucked with the /etc/pam.d/common-auth file and added a one liner.
Code:
auth    [success=die default=ignore]    pam_localuser.so

This disables any account access for accounts in /etc/passwd. Root is in that file and everything that is in /etc/cron.d is run as root currently on the system. Since /etc/pam.d/cron has a line to include "common-auth" it also denies access to any local account, therefore cron fails. It's a really weird fail because root can run "crontab -[ler]", add its own commands etc. but anything that runs from the cron daemon fails that check during execution with a very non-descript error in the log.

Code:
Oct  1 15:04:27 solar-assistant cron[390]: (CRON) INFO (pidfile fd = 3)
Oct  1 15:04:27 solar-assistant cron[390]: (CRON) INFO (Running @reboot jobs)
Oct  1 15:17:01 solar-assistant cron[390]: Permission denied
Oct  1 16:17:01 solar-assistant cron[390]: Permission denied
Oct  1 17:17:01 solar-assistant cron[390]: Permission denied
Oct  1 18:17:01 solar-assistant cron[390]: Permission denied

After I removed that one line from the common-auth (which essentially puts it back to its default state, I ran a diff on all common-* files after I reset and this was the only change) cron works again:
Code:
Oct 12 08:17:01 solar-assistant CRON[21739]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 09:17:01 solar-assistant CRON[27582]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 10:17:01 solar-assistant CRON[1207]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 11:17:01 solar-assistant CRON[7209]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 12:17:01 solar-assistant CRON[13225]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
 
Solar Assistant said they will fix the PAM.

I modified the code so you can just plug in any USB stick and it will auto create the directory for you, made calls absolute paths for security reasons and it auto creates the mount point too if you haven't created it. All in all I just buttoned up the code a bit :)
 
Solar Assistant said they will fix the PAM.

I modified the code so you can just plug in any USB stick and it will auto create the directory for you, made calls absolute paths for security reasons and it auto creates the mount point too if you haven't created it. All in all I just buttoned up the code a bit :)
He didn't ask how you were in the OS to even see those permission denied errors? :p
 
Solar Assistant said they will fix the PAM.

I modified the code so you can just plug in any USB stick and it will auto create the directory for you, made calls absolute paths for security reasons and it auto creates the mount point too if you haven't created it. All in all I just buttoned up the code a bit :)
That is actually a bit disturbing because he was claiming that he was soon releasing a backup feature in SA and now he is willing to help people create their own, couple that with the fact that I also see that he has removed that promise from the wish list and it does not look good.
I am happy for you but I was really hoping that he would create a scheduler for backups and a restore function in the software itself.
 
He didn't ask how you were in the OS to even see those permission denied errors? :p
Nope, but he did warn to be careful with adding more stuff to the system and having the SD card write more than it should possibly breaking the card.

Now that I opened up a somewhat informal channel with him, I hope to persuade him more to update the shipped version of Grafana to a newer one and maybe allow people to make their own charts. The original one is not in the database, it's in a hard coded JSON so there is no chance of messing that one up even if he granted grafana use access. The problem is that you can't log into Grafana when you're accessing it via Solar Assistant, you have to do it on the native/direct port which is locked down to only allow access on localhost by default.

I also mentioned the logs on ramdisk not logrotating :)
 
That is actually a bit disturbing because he was claiming that he was soon releasing a backup feature in SA and now he is willing to help people create their own, couple that with the fact that I also see that he has removed that promise from the wish list and it does not look good.
I am happy for you but I was really hoping that he would create a scheduler for backups and a restore function in the software itself.
He might very well be working on the backup solution that will be done not via cron but internal to the rest of the Solar Assistant framework.

He's not enabling anything for users, the code is still very much locked down and there was significant effort put in place to hide it. We call it "security via obfuscation" which is never a good way to go with security :) He's fixing cron being broken on everyone's system, but it doesn't do much other than some log rotation.
 
That is actually a bit disturbing because he was claiming that he was soon releasing a backup feature in SA and now he is willing to help people create their own, couple that with the fact that I also see that he has removed that promise from the wish list and it does not look good.
I am happy for you but I was really hoping that he would create a scheduler for backups and a restore function in the software itself.
The PAM issue is something broken in the installation of Solar Assistant. It doesn't break any user-facing functionality, but it prevents scheduled cleanup tasks from running, like log rotation and the like. In my view, although you need a working cron system to implement scheduled backups, fixing the PAM issue is very unrelated.
 
Nope, but he did warn to be careful with adding more stuff to the system and having the SD card write more than it should possibly breaking the card.

Now that I opened up a somewhat informal channel with him, I hope to persuade him more to update the shipped version of Grafana to a newer one and maybe allow people to make their own charts. The original one is not in the database, it's in a hard coded JSON so there is no chance of messing that one up even if he granted grafana use access. The problem is that you can't log into Grafana when you're accessing it via Solar Assistant, you have to do it on the native/direct port which is locked down to only allow access on localhost by default.

I also mentioned the logs on ramdisk not logrotating :)
Use ssh port forwarding for 127.0.0.1:3000 and admin/admin for grafana.
 
Solar Assistant updated
2022-10-30
 

Attachments

  • 2022-11-02 (1).png
    2022-11-02 (1).png
    334.2 KB · Views: 72
  • 2022-11-02.png
    2022-11-02.png
    294.9 KB · Views: 73
Last edited:
Oohh nice - I just updated and the MQTT controls for many other settings are now working.

Up to now I've only been able to control from HA (and Node Red) the Load Source Priority and the Charger Source Priority but nothing else.

Now I can adjust all these:

Screen Shot 2022-11-03 at 12.34.28 pm.png

The one I'm most interested in is the Max Grid Charge Current setting.

I tested it and it works.

I have automations to change the Load Source Priority and also to turn on supplemental charging using energy from my grid tied PV array but I haven't been able to automate the rate of supplemental charging, be it 2 A, 10 A, 20 A etc.
 
Hello,

I'm not posting here for a problem with Solar Assistant but as you use Solar Assistant I would like to have your opinion on the behavior of my MPPT tracker at low light.

If you think I'm straying too far from the topic, I'll delete my post.

I'm new to this forum and this is also the first time I've put up a system with solar panels.

I have an EAsun SMX II 5.6kW AIO ( SRNE HF4850S80-H rebranded ) connected to Solar Assistant (more info in my signature).
The behavior I will describe below is visible on the EAsun screen and also in Solar Assistant.

I have a string of 8 Jinko 415WC panels (STC values) :
  • Voc = 8 x 37.92 = 303.36V
  • Vmp = 8 x 31,32 = 250,48V
  • Imp = 13.25A
MPPT input voltage range 120~450 VDC.

As this is my first experience I wonder if the behavior of my MPPT tracker is normal ?

In low light the MPPT tracker scans the voltage from high to low (90V) continuously and stabilizes only when it receives 0.9A from the PV string.

During this scan the low power coming from the PV is not lost but the production is in sawtooth...

Is this normal behavior ?

Thanks for your feedback

04_PVCurrent - MPPT and low light.png
04_PVVolt - MPPT and low light.png
04_PVPow - MPPT and low light.png
04_BatCurrent - MPPT and low light.png
04_BatPow - MPPT and low light.png
04_BatVolt - MPPT and low light.png
 
Last edited:

diy solar

diy solar
Back
Top