Query of battery data does not work

[brumark]

Bug description
The e3dc-rscp adapter has a problem with the query of the battery data from my E3DC S10 system. It seems that all the other namespaces are working fine. I already saw that the adapter will only query up to 4 batteries, but my system has 5 batteries and supports up to a maximum of 6. In the object tree, there is only an empty folder with name BAT. The query for the battery is activated in adapter configuration. With the program RSCPGui I can read all battery data from my system.

Reproduction
Steps to reproduce the behavior:

1. Install adapter
2. Start adapter
3. Check object tree
4. BAT data is missing

Expected behavior
Battery data is present in object tree.

Screenshots & Logfiles
I switched the log level to silly and restarted the adapter. You can find the beginning of the log in the uploaded file.
e3dc-rscp_log.txt

Versions:

• Adapter version: 1.0.2
• JS-Controller version: 3.3.22
• Node version: 14.18.2
• Operating system: Raspbian GNU/Linux 10 (buster)

Additional context
None.

[git-kick]

First brief analysis:

• increasing max. battery count to 6 is easy; I will do so during fix of this bug
• BAT folder in object tree is empty because adapter receives three "Error 6" responses for four TAG_BAT_REQ_DATA queries - investigation needed what's going on (strange thing is that the current implementation works for many other installations)

1. Why only three responses? Timing issue?
2. How does RSCPGui query "all batteries"?

[brumark]

I don't know if it helps, but in RSCPGui you have an export function to various destinations where you can select every single value for recording. The tree to select the values is created dynamically and is reflecting the actual system.

As an example a path to Full Charge Capacity for batteries 0 - 4:
E3DC/BAT_DATA/0/BAT_DATA/BAT_DCB_INFO/0/BAT_DCB_FULL_CHARGE_CAPACITY
E3DC/BAT_DATA/0/BAT_DATA/BAT_DCB_INFO/1/BAT_DCB_FULL_CHARGE_CAPACITY
.
E3DC/BAT_DATA/0/BAT_DATA/BAT_DCB_INFO/4/BAT_DCB_FULL_CHARGE_CAPACITY

[git-kick]

@brumark, please test after installing from
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/Issue85
I have set the max. BAT count to 6 and now the adapter uses TAG_BAT_REQ_DCB_COUNT for probing the BATs, like RSCPGui does.
(I cannot test effectively because I have only 1 battery and probing with TAG_BAT_REQ_ASOC works in my setup.)

[brumark]

I tried your fix, but still no battery data available.

The request TAG_BAT_INDEX for index 0 and TAG_BAT_REQ_DCB_COUNT shows no reply in the log, also no error.
Because my system has only BAT index 0, all the other request causes an error.

Please check the log file:
e3dc-rscp_log_2.txt

Thanks for your effort to save this issue.

[git-kick]

I just realized that the official tag-list states for TAG_BAT_INDEX: "Index des angefragten Gerätes (Im Moment immer 0 bei der Batterie), kann in der Anfrage und in der Antwort vorkommen." I.e. probing for BAT_0..5 does not make sense. I will adjust that to probing only for BAT_0.

[git-kick]

e3dc-rscp_log_2.txt
shows that TAG_BAT_REQ_DATA request still returns
TAG_BAT_DATA - type: 0xFF - Error - length: 4 value: 6
which means that using TAG_BAT_REQ_DCB_COUNT for probing the BATs (instead of TAG_BAT_REQ_ASOC) does not help.
Further investigation needed how exactly RSCPGui does the first BAT request.

[git-kick]

Here is the code snippet from RSCPGui (rscpguimain.py):

The three r = ... and r += ... lines show how the first BAT request is built from

1. BAT_REQ_DATA
2. BAT_INDEX
3. BAT_REQ_DCB_COUNT

and that is what we are doing in e3dc-rscp as well.
So I am perplexed...

@brumark: I can offer to do another try using BAT_REQ_INFO. I have modified the code here:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/Issue85
(I tested it successfully in my environment.)

In addition, I suggest you post some more details about how your devices are set up - E3/DC model, battery model(s), initial number of batteries, additional batteries, in extra case? ... This could help to identify the reason why BAT requests are not working in your installation (we have no other complaints in >100 adapter installations).

[brumark]

@git-kick: With the last release you fixed the problem. Now I can see all battery details in the object tree.
Thank you very much for the fast fix!

For documentation purposes here is the abbreviated log output:
e3dc-rscp_log_3.txt

In the object tree I found one minor cosmetic issue. In the DCB_CELL_TEMPERATURE folder only 6 out of 8 possible values are displayed for my batteries, which is correct. But the two empty values are wrongly named with "Zellspannung" and 0V instead of "Zelltemperatur" and 0 °C.

As a further development, I could imagine having one more time interval to choose from.

Thanks for the great adapter.

[git-kick]

Surprise!
Good: it works for you.
Bad: I don't know why :-/
Anyway, I will include the BAT_REQ_INFO tweak in the next release.

Concerning DCB_CELL_TEMPERATURE, the meaning of elements 05, 06 and 07 heavily depends on the battery make/type, see forum discussion. Currently we use a simple work-around for displaying DCB_CELL_TEMPERATURE elements:

if( value > 4.5 ) then display_as_temperature else display_as_voltage

The assumption behind is that nobody will install the batteries in a place colder than 5 °C, because this will void warranty.
In your case, it seems that 05 is a temperature and 06 and 07 are empty (not a "frozen battery", right?)

So perhaps it makes sense to add a third case

if( value = 0) then display_as_null

for better cosmetic look. What do you think?
(You can try it with https://github.com/git-kick/ioBroker.e3dc-rscp/tree/master which is the v1.0.3 preview)

[brumark]

I didn't know about the discussion in the forum. For me it would be also ok if you leave it like it is or if (value = 0) then 0 without unit. And you are right, my battery isn't frozen :-).

One last question: Why is battery SOH (State of Health) named ASOC in the object tree?

Thanks again.

[git-kick]

Welcome!
ad ASOC: its the tag name used by E3/DC which I do not want to alter, see forum

[git-kick]

Fixed with V1.0.3