Unknown tag 0x100003E in response to EMS_REQ_GET_MANUAL_CHARGE

[torbennehmer]

Hi @fsantini,

with the most recent firmware upgrade of the E3DCs, the API for EMS_REQ_GET_MANUAL_CHARGE seems to have changed.

Seen in

• 16777278 is not a valid RscpTag torbennehmer/hacs-e3dc#114
• Werte in Basis werden nicht mehr angezeigt rxhan/RSCPGui#47

In my case this is triggered by this code snippet:

e3dc.sendRequest((RscpTag.EMS_REQ_GET_MANUAL_CHARGE, RscpType.NoneType, None), keepAlive=True)

Resulting in this Stacktrace:

 File "/usr/local/lib/python3.12/site-packages/e3dc/_e3dc_rscp_local.py", line 102, in sendRequest
    receive = self._receive()
              ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/e3dc/_e3dc_rscp_local.py", line 76, in _receive
    decData = rscpDecode(self.encdec.decrypt(data))[0]
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/e3dc/_rscpLib.py", line 263, in rscpDecode
    return rscpDecode(rscpFrameDecode(data)[0])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/e3dc/_rscpLib.py", line 279, in rscpDecode
    innerData, usedLength = rscpDecode(data[curByte:])
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/e3dc/_rscpLib.py", line 270, in rscpDecode
    strTag = getStrRscpTag(hexTag)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/e3dc/_rscpTags.py", line 3692, in getStrRscpTag
    tag = RscpTag(tag)
          ^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/enum.py", line 744, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/enum.py", line 1158, in __new__
    raise ve_exc
ValueError: 16777278 is not a valid RscpTag

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/e3dc/_e3dc.py", line 226, in sendRequest
    result = self.rscp.sendRequest(request)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/e3dc/_e3dc_rscp_local.py", line 108, in sendRequest
    raise CommunicationError
e3dc._e3dc_rscp_local.CommunicationError

The workaround of @kobelka in #108 will hide the problem, however it doesn't really solve it. I can't reverse engineer that at the moment as my E3DC is still using the old firmware.

I'm not sure, what the best approach would be at the moment for pye3dc. For HACS-E3DC, i'll disable the piece of code for the moment as a hotfix, as its around manual charging, we'll probably can live with that for the moment.

[fsantini]

Uhm, the tag is not present in the rscp library of the portal website, at least the version that is loaded for my system...
https://s10.e3dc.com/s10/js/rscpLibV0.9.3.min.js

[torbennehmer]

@fsantini same here, nevertheless we seem to get it out in the wild. The core parser code in pye3dc then fails on this. Apparently this came in with the latest firmware, which I did not get yet (2024_06 or something like that, see the referenced bugs).

Maybe adding some kind of catch which handles such cases gracefully would be an idea? In the meantime, I'll disable the above call in the HA integration to get it working again.

[gamer123]

@fsantini how can i provide this kind of java file for my system with the latest FW 2023_06 ?

[fsantini]

This is in Firefox. Open your portal page. Click on the three horizontal bars button to open the menu and choose More Tools:

Then click on Web Developer Tools.
In the bottom window that opens, click on the "debugger" tab, and then search for the file rscpLibVXXX.js in the left pane.

[gamer123]

@fsantini Thanks. The result is good or bad, depends. The files are the same.

Winmerge Left side is mine, right side is yours.

[torbennehmer]

@fsantini same here, and in the new portal (my.e3dc.com) I can't even identify something like this, everything's hidden behind the backend here.

I've had a thought: What about hardening the code against unknown tags? If we can't parse them, instead throwing an exception, we instead add the result with its hex code or something like this, effectively mimicking the tag, so that we don't crash? That would give us more resilience at least, also allowing easier reverse-engineering, if necessary. If you like the idea, would you need help in implementing something like this?

[kobelka]

@torbennehmer and @fsantini Maybe E3DC can provide us with further information, I opened a ticket there and now received a query from E3DC:

Dear sir ...,

The hex code you use for the RSCP TAG does not exist in our current system.
Can you please send me the plain text name of the RSCP TAG so that I can pursue the case further or clarify the reason for it.

Thank you for your patience and cooperation.

Best regards,

Your E3/DC team

Can you give me the answer that I can then forward to E3DC?

[torbennehmer]

@kobelka We are querying TAG_EMS_REQ_GET_MANUAL_CHARGE (0x0100008E) and try to parse the response against the list of known tags (the RSCP-tags-official excel file one can download).

[torbennehmer]

@fsantini I have an idea what this tag could mean, when looking at the new portal, there is an information when you can again initiate manual charging, maybe this is the new tag?

[torbennehmer]

Hi @fsantini,
I've probably identified the tag, it contains the last target Wh you set for manual charging. I'll give you a PR that should fix it with a clear tag name. The waiting time is unfortunately not part of the datagram. I'll validate that further with a few more random manual charges (once the waiting period is over)... In parallel I'll get you an PR.
Cheers, Torben

[torbennehmer]

Hi @fsantini , thanks for merging #117. Would it be possible that you push out a new release with this fix? I'm currently upgrading a number of dependencies, including HA itself, for the HA integration and would like to pull in that fix as well at that opportunity.
It would be fantastic if that would be possible.
Cheers, Torben