diy solar

diy solar

Solar Assistant - data logger

You can gain root access to solar-assistant, it's an easy way to go.
get your sdcard into an other raspi or linux machine

Next modify:
Like GregTR here said: do delete the line

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
I was able to do steps 1 & 3, but when I tried finding /etc/pam.d/common-auth there was no /etc/pam anything. Being unfamiliar with this particular os, can you off some supporting guidance please?

Thanks in advance
 
Hello! I'm new around here. I've searched for relevant info to no avail...
I wanted to try Solar Assistant, but the RS485 ports on my inverter are all occupied (3 of them: Smart Meter, battery, backup box - that switches to battery in case of grid outage). Seeing that RS485 is not a one to one protocol (and is master/slaves), is it possible that I can connect it in parallel somehow?
Thanks!
 
It's a shame the guys at solar assistant promised "configurable alerts/email notifications" since late last year and up till now there are still shifting the expected date. Deceiving people into purchasing their product.
 
That's a bit over the top I think.
I don't think so. It's one of the feature that made me go for it. What they essentially do with new updates is adding support for more inverters. I want to get notified when my battery is going down or when there's a warning or alarm. No one wants to watch the log all the time.

Edit: It shouldn't take forever for the feature to be added. Solar assistant is web based, it can easily tap into PWA to make it possible. Or if they don't want to implement it, they should not lock ones device so one can use one device for both this and home assistant. Or they should give users the option of bundling home assistant into it.
 
It's one of the feature that made me go for it.
So you bought it only for a feature that was not yet implemented and which indicated an estimated date it would be and consider that deceptive.

OK.

Or if they don't want to implement it, they should not lock ones device so one can use one device for both this and home assistant. Or they should give users the option of bundling home assistant into it.
Or you can just add Home Assistant on a separate server like everyone else does. I would not want SA and HA on the same RPi, that would have potential performance issues.

The fact it requires a standalone RPi was not unknown when purchased, so that clearly wasn't a deal breaker for you.
 
BTW what would happen if I hooked my single EG4LL into the Pi while I am still getting my closed loop battery info for my other four eFlex packs from the Inverter. I suspect that SA would show me only the SOC of the EG4? That is why I have not bothered trying but now I am curious to know if I would see them as separate numbers.

I tried this with my two EG4-LL v2 batteries and the SOC and voltage was accurate, but the displayed and logged battery power was only for slave battery.

Anybody else been running it for over a year?
I have noticed the update time has really slowed down as the database grows. It will sometimes react to a load change in 2-3 seconds and at other times it will take 10-15 seconds to react.
As soon as I know Sol-Ark has migrated my data safely to their new server I am putting in a new SD card with a fresh install and see if a clean Db fixes the issue.

I noticed the delay when running closed loop communication with EG4 6000EX and EG4LL v2 batteries. As soon as I switched SA battery setting from “Inverter Value” to “Modbus RS232/RS485”, the real-time data no longer lagged.
 
Hello, I've been using SA since the middle of last year. This evening it stopped giving me access to the https://r*****d.eu.solar-assistant.io/ site or the android app but I can still access it on my local network, 192.168.1.***. I updated SA to the latest 2023-02-28 software but this didn't solve the problem. What is the next step to solve this issue?

Thanks in advance, Greg
 
Hello, I've been using SA since the middle of last year. This evening it stopped giving me access to the https://r*****d.eu.solar-assistant.io/ site or the android app but I can still access it on my local network, 192.168.1.***. I updated SA to the latest 2023-02-28 software but this didn't solve the problem. What is the next step to solve this issue?

Thanks in advance, Greg
having the same issue since tonight..
are you in the eu ?
 
I know the dashboard has the data but would be great to have a flow diagram option(with moving lines) for those of use that keep an ipad display up all the time. Probably the only thing SmartESS does any good is this one screen :).

Screenshot 2023-07-17 155324.jpg
 
You can gain root access to solar-assistant, it's an easy way to go.
get your sdcard into an other raspi or linux machine

modify sshd_config like this one:


Bash:
# This is the sshd server system-wide configuration file. See

# sshd_config(5) for more information.


# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin


# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented. Uncommented options override the

# default value.


Include /etc/ssh/sshd_config.d/*.conf



Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::


#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key


# Ciphers and keying

#RekeyLimit default none


# Logging

#SyslogFacility AUTH

#LogLevel INFO


# Authentication:


#LoginGraceTime 2m

PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10


PubkeyAuthentication yes


# Expect .ssh/authorized_keys2 to be disregarded by default in future.

#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2


#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes



# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no



# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication no



# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no


Next modify:
Like GregTR here said: do delete the line

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


modify shadow
1.line:
/etc/shadow

root:$y$j9T$ENxjb9crH9Rf43ZvEU5K//$gUc0L1WSGNRiLA5a1w5vxKONSaa2LrxThvcoyShmVh8:1

so root password will be: 1234

reboot and ssh into your solar-assistant ip as root and password: 1234

easy:)
A little confused.

i can't find that line in /etc/pam.d/common-auth

am i supposed to add it?
 
A little confused.

i can't find that line in /etc/pam.d/common-auth

am i supposed to add it?
This is what mine looks like now :

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)

# following was in from solar assistant i removed it
# auth [success=die default=ignore] pam_localuser.so

# end of pam-auth-update config


Notice the lines that are :

# following was in from solar assistant i removed it
# auth [success=die default=ignore] pam_localuser.so


This is a comment I made and the line I commented out.
The # at the start makes anything on that line a comment. This way I have what they put there
still there to know what I changed it from.
 
I couldn't get fips process to work so had to use a second raspberry pi to mount the file systems and edit the files:
https://windowsreport.com/authentication-token-manipulation-error-raspberry-pi/

Edit cmdline.txt file and add( init=/bin/sh) to bring up the raspberry pi to a shell(with hdmi console and keyboard).
Change root password.
set roots shell:
chsh -s $(which sh) root

Then edit back the cmdline.txt


Changed in sshd_config file:
UsePAM no
PermitRootLogin yes


I used a second raspberry pi and a usb cardreader to mount the filesystem needed.
mount /dev/sda1 /mnt (to get to the cmdline.txt)
or
mount /dev/sda2 /mnt (to get to the sshd_config file)
make sure you umount when done editing file!!.

SSH into the raspberry pi with root and password you set.


The above is not a how-to or instruction and was done from memory. YMMV, make sure you have a backup or ok with re-imaging your sd card... If it work maybe someone can document and publish better instructions....
Thanks
Kevin
 
One thing to point out for anyone buying a pi for this or actually even if your running certain pi's. SD cards are a BAD idea for a live os. Period. They are not designed to be rewritten a bunch and will fail.

I recommend going with a pi that has emmc memory like the orange pi 3 lts or anything else that has something other than requiring you to use a sd card.

Even attaching a ssd to it would be better for long term hassle free usage.

If you use a pi with an internal memory drive like I mentioned above you can modify it and back it up anytime you want effortlessly and FAR faster than other methods.

You install the solar assistant image to the internal drive and then boot on a sd card with a linux type os. I used the factory stuff my pi runs. Using this method allows you to boot up on that sd card and then edit the files that are on the internal drive anytime you want. When your done making changes or backing up the internal drive to the sd card you simple reboot the pi and remove the sd card. Presto you back on your live system with changes in place.

This is how I set mine up when I installed webmin and other remote tools to it and modified it to allow logging into the command prompt aka ssh shell.

I can ftp to it, edit files etc while its running with changes I made.

Only thing I would caution on is to not "upgrade" anything. The package manager on mine shows 82 packages need updating.
This would be a risky move since we have no idea what all was patched and what versions are going to be compatible with solar assistant.

So don't update anything. Installing new programs should be fine just no updates.
 
Back
Top