Question: Running as a service instead of docker?

[JensHoRi]

Hello,

because I have DEYE600 and DEYE300, I'm searching a solution to read out directly.

Because I have an ubuntu running 24/7, my question: Can I run this as a service without docker too?

[kbialek]

hi @JensHoRi

Very likely it will work. In the Makefile there is run target that starts the daemon directly, without using docker. You can take it as an inspiration when writing your systemd unit files.

[JensHoRi]

Ehm, I'm able to write a service file, but not familiar with make shame

If you have just the command to start from commandline, I will try the rest. Would be much appreciated

[kbialek]

Here is the command

bash -c "$(cat config.env | xargs) python deye_docker_entrypoint.py"

Please note, that this must be run in a python environment with required dependencies installed. See requirements.txt file

[JensHoRi]

Just an update: Was able to create environment, but only able to start with make run in the foreground :/

will look further at weekend, because now microinverter are off (out of sun).

if it works, do you think could be an option to make an config.yaml for the settings and assist more then one inverter in one cron?

If you like the idea, I will try to help developing. (If the python works with my inverters of cause, otherwise I could not test.)

[kbialek]

@JensHoRi

if it works, do you think could be an option to make an config.yaml for the settings and assist more then one inverter in one cron?

I'm not a big fan of this change. The current implementation assumes that it connects to a single inverter. Changing this would require many changes across the project. This, in turn, will increase project complexity.

Instead, if you want to monitor two inverters, you can start two instances of the deamon, each using a dedicated config file. The daemon itself has quite low cpu/memory footprint, so it shouldn't be a problem, I suppose.

If I may ask, what is your motivation against using docker? It should run flawlessly on your Ubuntu server.

[JensHoRi]

I‘m just not familiar with docker and less Programms means less security issues. So not really something against.

can report Bosswerk mi600 (=deye Sun 600) with serial 410xxx works.

Will check mi300.1 later.

With Bosswerk some preparation is needed to listen in local Wi-Fi on 8899, because it’s a secured field in config_hide menu.

If interested I can add a howto in your main page ;)

and add the service script

[JensHoRi]

Can be closed

[JensHoRi]

One question: In your table some values are classified with "micro,string" and some are empty. Saw in you script, those are in no group in scripts, but still used in both. Wouldn't it make sense to add micro,string in this case too?

[kbialek]

At the current state of the project, it might have sense to unify this. However, the protocol spec also covers "hybrid" inverters, which are currently not supported by this project. Perhaps someone will come up with a PR that will add mapping of "hybrid" inverter registers. Then this classification will make sense.

[JensHoRi]

O.K., I just asked, because e.g. the Deye SUN 600 seems to have on one site some registers not filled, furthermore there are more and additional fields in other registers. So I just think about further development, If every sensors would be in a group, this would easily make it possible to have e.g. micro, string, hybrid as a very general profile and just enter groups for specialized inverters. Not really sure, but I believe the actual registers are the common sunspec-specifications used by deye and some others.

I searched a lot, but want to say: Your script is definitly the best working I found for my inverter.

[kbialek]

Exactly, that is the idea. Not everyone needs to collect data from all registers. More groups can be added in the future, e.g. "battery". I've not added them so far, because I do not need them :smile: If someone has such a need, then a PR is highly welcome.

I searched a lot, but want to say: Your script is definitly the best working I found for my inverter.

Thanks. Yeah, I've also searched a lot, before starting this project :smile:

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.