Request for support com.victronenergy.solarcharger about dbus-mqtt-devices HOT 33 CLOSED

OK.
As I understand, you have already a real solarcharger.
My approach for a up to than unsupported device for this driver (pv-inverter) was:
0. install MQTT Explorer

1. get all topics via MQTT Explorer of the real, working device
2. add solarcharger to service.yml
3. let the driver register a solarcharger
4. fill some topics of the the new charger with data via MQTT Explorer

Maybe you already did all that.
Right now I don't have a test system running for active help.

from dbus-mqtt-devices.

Hi, sounds like an interesting project.

I see the device popping up and showing some numbers, but it stays in not activ status.
Can you explain more? If you stop the driver or disconnect from MQTT with a Last Will message (as recommended) the then dbus will show the device as disconnected.

Have you check the troubleshooting tips in the Readme?

from dbus-mqtt-devices.

For examples, take a look in the test-data folder and the various simulator scripts provided.

from dbus-mqtt-devices.

Yes i did, i even wrote a test-data script for this charger-tests.
My current guess is that it does not work because of the missing "ErrorCode"-Part.
But i cannot configure this because then the Device dissappears totally. I hoped that someone finds the error or maybe there is a change needed somewhere in the code?

import paho.mqtt.client as mqtt
import json
import copy

clientid = "ch001"

registration = {
  "clientId": clientid,
  "connected": 1,
  "version": "v0.2",
  "services": {
    "ch1": "solarcharger"
  }
}

unregister = copy.deepcopy(registration)
unregister["connected"] = 0

data = {
    "ProductId": 41074,
    "NrOfTrackers": 1,
#    "Connected": 1,
    "Pv/P": 22,
    "Pv/0/P": 23,
    "Pv/V": 81,
    "Pv/0/V": 81,
    "Dc/0/Current": 3,
    "Dc/0/Voltage": 53,
#    "Link/NetworkMode": "13",
#    "MppOperationMode": "2",
#    "Yield/Power": 300,
#    "ErrorCode": 0,
    "State": 1,
#    "Mode": 1,
}

from dbus-mqtt-devices.

Can you upload the whole script? How are you using that data variable?

from dbus-mqtt-devices.

Here the 2 Files.

BTW. Thank you A LOT for this project!!!!

As soon as i uncomment the ErrorCode - Part in the service.yml, it doesnt work.

charger-simulator.zip

from dbus-mqtt-devices.

BTW , maybe we can post the nodered-flow to fill the data with values in the installation instructions?
Maybe this helps others aswell, and as victron includes nodered in venusos directly, it is a very easy way to use such virtual devices!
I can provide my currend flow if needed!

from dbus-mqtt-devices.

As soon as i uncomment the ErrorCode - Part in the service.yml, it doesnt work.

Is there an error in the log file?
more /var/log/dbus-mqtt-devices/current

Does the error happen during device registration or when you publish data. Do you know which part of your code triggers the error?

from dbus-mqtt-devices.

The Error seems to be

ERROR:device_manager:Unexpected error: <class 'yaml.scanner.ScannerError'

EDIT: No, error tells me that i missed a : in the definition! Everything ok!

from dbus-mqtt-devices.

That sounds like a YAML parsing error. Looking at your settings files, I can see you have a missing colon ":" after ErrorCode

ErrorCode: # colon required here. 
#    description: "0=No Error"
#    default: 0 # not showing in in console???
#  Connected:
#    description: ""
#    default: 1 #

If in doubt, copy paste your yaml file into any of the online yaml verification tools you can find online.

from dbus-mqtt-devices.

Haha, I didn't see your edit. Glad you spotted the error too.

from dbus-mqtt-devices.

Sorry, didn't want you to invest time in an already found error....

Unfortunately, I cannot get it to work.
Do you know anything about this errormessage?
How can I debug this? The errormessage of your driver does not give any hint what is going on.....
It worked for a short periode of time, but since a reboot, all previous verions of the config do not work anymore.
I tried for hours, without any success...

from dbus-mqtt-devices.

Again, let's split the problem in half. Is that after device registration or after registration and sending data?

from dbus-mqtt-devices.

OK, i checked that. This Message appears right after the registration.
So i have to change the service.yml to find the problem, right?

from dbus-mqtt-devices.

Ok, things change without any change.
After a reboot, i can register the device and it pops up. THe message about beeing incompatible
now just appears when sending data.
I changed the data a lot, but the message keeps appearing. I think I am at a dead-end here.... :(

EDIT: What i see is I get an "BMS connection lost" Alarm at regular solar chargers when sending Data to this device,
although i currently to not send any Network, BMS or other values. So I think these values are saved between
"./test-data/charger-simulator.py"
calls?!? To be shure i deleted the "W/.../solarcharger" MQTT path, but the result didn't change.

from dbus-mqtt-devices.

I can see some incorrect paths in your services.yml
See https://github.com/victronenergy/venus/wiki/dbus#solar-chargers

/SYSTEM should be /System for example.

from dbus-mqtt-devices.

Okay, i see, but this is outcommented long ago since i don't need is currently.
I am just trying to find a minimal configuration which works, but i am unable.
When i compare the topics to my hardware-device, there are some differences. maybe the dokumentation is
little outdated. I'm lost here, so unfortunately I am giving up...

from dbus-mqtt-devices.

Without reading the whole issue, this is my Tasmota approach. It works reliable and robust.

Is your added system really a solar charger (connected to the battery) or a additional PV inverter?

Sebastian

from dbus-mqtt-devices.

@stundenblume, thank you. But you register it as pvinverter,
I need to register it as solarcharger...

from dbus-mqtt-devices.

Yes I did that. Thank you anyway for trying to help me!!
There are differences between my real systems and the Dokumentation. For example /Pv/V and /Pv/0/V

I didn't find out which one works, as in this case no solution worked.
But I do use the virtual battery and other devices and this works very well!!

from dbus-mqtt-devices.

I have a Question for understanding:
What is the better way to try: Better fill services.yml with the values and then try to fill them with mqtt, or
keep services.yml small and try different values with mqtt (are values not configured in services.yml ignored?), or do they have to be in sync at every time?
Do you have a restart-script for the Service? Currently i reboot at every change.

from dbus-mqtt-devices.

Hi, you need to set up your required settings in the services.yml before sending values by Mqtt. I would try to focus on a minimal set of settings first.

If you edit the /data/rc.local and comment out the line that executes starts the driver, you can use that same command to run from the command line. The log output will come stratum to your console too. If you make a change to services.yml, Control-c will kill the driver so you can restart it.

After you make a change to services.yml, restart the driver and just monitor it for 15 mins before sending any data. Then register a single device with that service and monitor again for 15 mins. If all ok then try sending some data values over Mqtt.

Are you still getting the same error?

from dbus-mqtt-devices.

Thank you, I will test it.
Unfortunately, I cannot have "long" downtimes of your great service, because i use the virtual battery in production
and it is very helpful/stable! A Really great service you developed here!!

Yes, I still get the same message, regardless what values i try to send. It worked for a very short time at the beginning, but i am not able to reproduce this, although the config which worked is available.
I thought that maybe i have some spare-values in my victron-config as vrm shows me a vebus-device in the gui which does not exist and which does not show up in the device-list. So maybe in need a factory-reset?!

from dbus-mqtt-devices.

Can you set up a second RasPi for testing? There should no other hardware be necessary.
I did that when I was playing with the services.yml and pv-inverter.

from dbus-mqtt-devices.

I did. Same error message. I think I just need the first correct values to Start... 😏

from dbus-mqtt-devices.

Maybe i missunderstood ProductId:.
When to use a real ProductId, when to use 65535#
I saw noth, when I choose 65535, it is displayed.

from dbus-mqtt-devices.

Victron's documentation for Product Id is not that useful.

"As defined in products.h in velib."

As far as I can tell products.h is closed source. So I just set it to a constant value for all my use cases and it worked ok.

from dbus-mqtt-devices.

I am just reading the Victron docs for Solar Charger devices. I don't think you should be mixing numbered and unnumbered attributes, for example:

  Pv/P: # 
    description: "W"
    persist: true
    default: 0
    format: "{} W"
  Pv/0/P: # 
    description: "W"
    persist: true
    default: 0
    format: "{} W"

The docs say:

PV Array voltages and currents:
/Pv/V             <- PV array voltage, path exists only for single tracker product (all common MPPTs)
/Pv/0/V           <- PV array voltage from 1st tracker
/Pv/x/V           <- PV array voltage from tracker x+1; today's max number of trackers in a single Victron product is 4.
/Pv/0/P           <- PV array power (Watts) from 1st tracker
/Pv/x/P           <- PV array power from tracker no. x+1. 
/Yield/Power      <- Total PV power (Watts).

  Two examples:
  1) a solar charger with one tracker has 2 paths:
  /Pv/V
  /Yield/Power

  2) a solar charger with two trackers has 5 paths:
  /Pv/0/V
  /Pv/0/P
  /Pv/1/V
  /Pv/1/P
  /Yield Power

This suggests to me you should be using one or the other not both.

from dbus-mqtt-devices.

How did you determine 13 for the /Link/NetworkMode path?

/Link/NetworkMode     <- Bitmask
                      0x1 = External control
                      0x4 = External voltage/current control
                      0x8 = Controled by BMS (causes Error #67, BMS lost, if external control is interrupted).

The docs suggest to me that it should be 1, 4 or 8 (in decimal). I would think 1 would be a good place to start.

from dbus-mqtt-devices.

The Victron docs list two settings, so I think you should have these defined with "persist: true".

/Settings/BmsPresent         <- BMS in the system. External control is expected.
                                This happens automatically if NetworkMode is set to expect a BMS.
/Settings/ChargeCurrentLimit <- The maximum configured (non-volatile) charge current. This is the same as set by VictronConnect.

from dbus-mqtt-devices.

I just noticed you have persist: true on a couple of parameters that are not settings, I would remove the persist where it is not needed.

Pv/P: # 
    description: "W"
    persist: true
    default: 0
    format: "{} W"
  Pv/0/P: # 
    description: "W"
    persist: true
    default: 0
    format: "{} W"

from dbus-mqtt-devices.

This is all testdata.
As the ProductID i used seems to block every setting for the device, i had to many different
datas for tests.
Now with a non defined ProductID, it seems to work and i can try to find a complete config to share.
Thank you a lot!!

from dbus-mqtt-devices.

Do you have a restart-script for the Service? Currently i reboot at every change.

All services on Venus OS run under daemintools (https://cr.yp.to/daemontools.html)

From memory, you should be able to use the following command (from ssh command line) to top the service

svc -d dbus-mqtt-devices 

and the following command to restart it:

svc -u dbus-mqtt-devices

from dbus-mqtt-devices.