Solaregde plugin in docker volume. Works with error

[pgas37]

I installed domoticz in a Docker container and placed the data in a volume called domoticz_data to prevent data loss during a subsequent pull. The SolarEdge Modbus Python plugin is now installed in the data volume path root@44929adebcd4:/opt/domoticz/userdata/plugins#. However, the plugin occasionally returns an error. It appears the plugin is searching for/using the original location of the plugin path /opt/domoticz/userdata/plugins. How can I modify the plugin to prevent these errors?

thanks

[waltervl]

The / is correct as from inside the container it is and should be in /opt/domoticz/userdata/plugins

How does your docker compose yaml file looks like?

[jannl]

The plugin gives an occasional error since I use it.

The thing is the Solaredge Modbus TCP seems not to be real actively maintained.

I plan to look into that, but that will take some time before I have ehm time.

What I sometimes see is that shortly after modbus has an issue also the Solaredge API gets the errors, mostly when the sun is not shining or the panels are otherwise not generating electricity.

[waltervl]

I see also errors in your screenshot from the plugin manager plugin you have implemented? So it is not only the solaredge plugin that gives issues.
Perhaps it is an issue of your docker implementation that it sometimes cannot find the mounted volume? Is that a disk on the same system or a network disk?

Edit: It seems you have 2 issues:
1. Solaredge plugin just have an issue with communicating. Nothing to do with /
2. Plugin Manager (PluginList) plugin not able to locate the solaredge plugin.

[jannl]

Shouldn't the error in that case not occur always instead of occasionally?

[waltervl]

I dont know both plugins but please treat your errors as 2 different problems.....

[jannl]

Because of a lot of defunct processes in my Domoticz docker, I added

Code: Select all

init: true

to my docker-compose.yml. The line takes care of cleaning defunct proces and starts an initd (as I read) and takes care of a lot of things to let software inside a container.

Besides that I have not seen any errors, which I normally do see. Not sure if this is a good thing and the time is short since it runs, but who knows.

[waltervl]

I dont know what you all did but this adding of int: true should not be needed. It seems something else is wrong

[jannl]

Please learn, it is needed in some cases. For instance when you use os.execute in lua to start processes. Due to docker functionality you may get defunct processes that cause a container to crash eventually. Defunct processes can be checked by logging into a container and issue a ´'ps -ef´. So in my case it is needed.

Unfortunatwly it did not solve the Solaredge error, I had to wait longer

Edit: i a normal Linux environment, init always runs. With init: true , tini is started which is a small init.

[waltervl]

If those Lua os.execute actions are not treated in async you also could get Domoticz issues as they can hold up the complete event system.

You better switch to dzvents as that is better integrated and has async functions See for example discussion viewtopic.php?t=35932

[jannl]

async is the problem in this case, in combination with docker.

I will never go to dzvents because of different reasons. I started lua before dzvents and solved the multiple lua scripts issue just before dzvents started. Dzvents is propably easier to start with without programming experience.

But that is not the topic here.

[pgas37]

Thank you both for joining this discussion. However, the discussion becomes confusing when comments are somewhat cryptic, such as "/ is correct..." and "Edit: In a normal Linux environment, init always runs. With init: true, tini is started, which is a small init" and "I will never go to dzvents because etc, etc" from Janni.
Sorry, but often more explanation is needed for the relative layman.

Waltervl asks for the docker-compose.yml.

Code: Select all

services:
  domoticz:
    image: domoticz/domoticz:stable
    container_name: domoticz
    restart: unless-stopped

    privileged: true   # belangrijk voor USB hotplug

    ports:
      - "8080:8080"

    volumes:
      - domoticz_data:/opt/domoticz/userdata
      - /dev:/dev       # geef toegang tot alle devices

    environment:
      - TZ=Europe/Amsterdam

volumes:
  domoticz_data:
    name: domoticz_data

Waltervl noted "pluginmanager (pluginlist) not able to locate solaredge plugin." In my opinion this plugin-manager also looks at the /opt/domoticz/userdata/plugins/SolarEdgeModbus/ directory, which I don't use because my SE plugin is within the container (see first post).

Janni noted that async is the problem here, but at the same time he stated it's not the topic. Isn't that a contradictory comment?

In short, I don't see any clear solution in the answers.
Apparently, adapting the SE plugin to work within a Docker container isn't possible for the time being, although all sensors seems to work fine (except the log-errors ofcourse).
I asked a similar question at GITHUB/addiejansen (the source of all this) under Discussion and didn't get a single response.

Perhaps I should remove all the Domoticz data from the volume and place it in /opt/domoticz/userdata/, the default location. Perhaps that will solve all the problems.

[waltervl]

I think you should have volumes configured like

Code: Select all

- ./domoticz_data:/opt/domoticz/userdata

And the docker compose yaml file should be in the folder where the domoticz_data folder is.

Or make the volume a full path like eg

Code: Select all

- /home/pi/domoticz_data:/opt/domoticz/userdata

The pluginlist plugin looks at the plugins IN the container, not outside. And from inside they are in /opt/domoticz/userdata/plugins

[jannl]

This is my docker-compose.yml

Code: Select all

services:
  domoticz:
    #image: domoticz/domoticz:161125
    image: domoticz/domoticz:051225
    container_name: domoticz
    init: true
    restart: unless-stopped
    # Pass devices to container
    devices:
      - /dev/ttyUSB-RFXcom:/dev/ttyUSB-RFXcom
    ports:
      - "8080:8080"
     # - "443:443"
    volumes:
      - ./config:/opt/domoticz/userdata
      - ./config/.ssh:/root/.ssh
    environment:
      - TZ=Europe/Amsterdam
      #- LOG_PATH=/opt/domoticz/userdata/domoticz.log
    logging:
       driver: syslog
       options:
          syslog-address: udp://x.x.x.x:514
          syslog-format: rfc5424
          tag: domoticz

Don't mind the ssh volume, that is for issueing a command in the docker host.

[pgas37]

Thanks for sharing your docker-compose.

I have not seen before the. Volume xxx .ssh and the logging lines.

Could you explain the function of these lines and how to use them in, I assume, in the browser?

Thx

[jannl]

The .ssh is to be able to execute a shell command from within the container in the host. I use it to have domoticz send a wake on lan packet to my mini pc. Configurated innsuchba way it is the only thing the container can do via dsh. This to make sure any security issue with domoticz can not easily compromise the pi.

The log lineS are to send the container logging to a central syslog server. In this case my NAS.