[digitalstrom] Power Consumption and Energy Level NULL after DSS Update to 1.19.2

[alaub81]

Digitalstrom did an Update to dss Version 1.19.2. After I installed the update, all my power and energy values get no updates and if I add a new Item, the value is NULL.

It seems, that digitalstrom changed something here, so we do not get values anymore.

In the Release notes is written, that they improved something with the energy graphics.

I am using the openhab 3.2.0 docker image. Problem was in 3.1.1, too. I restarted the dss and also openhab was restarted a couple of times.

For me it seems that we have a new bug here.

To reproduce that Bug, you have to update the digitalstrom server to version 1.19.2. After that you will not see any item value updates on your power consumptions or energy levels. So it just keeps at 0. Interesting is, that the totalpowerconsumption, which belongs to the digitalstrom server thing, is still working.

I am using a Debian 10 Installation on a Raspberry Pi 4 with openhab docker image in version 3.2.0. The Digitalstrom Server is a dss20 with distroVersion 1.19.2

[ardanedh]

I can confirm the problem. A quick glance at the JSON results for getting meter values does not show any changes in the API.

If time allows, I'll try to dig into the digitalSTROM code. Meter values are not a high priority in my openHAB environment, though ;)

[ardanedh]

With digitalSTROM Server version 1.19.2, the JSON request (/json/metering/getLatest) to retrieve the meter values returns a dSUID instead of a dsid:

{
    "result": {
        "values": [
            {
                "dSUID": "303505d7f8000000000002c00000323c00",
                "value": 124.0,
                "date": "2022-01-04 20:46:02"
            }
        ]
    },
    "ok": true
}

The binding fails at this point to handle the meter values due to the missing dsid
I don't know if this is a bug in the new digitalSTROM server version or if this is by intent.
The latest digitalSTROM-Server JSON API clearly indicates the returned value should be a dsid.

Unfortunately, getting in contact with digitalSTROM is somewhat difficult, they seem to communicate mainly via Facebook (a service I don't use). I'm uncertain at the moment on what is the best solution to this problem ...

[alaub81]

last time I had problems with digitalStrom I used the mail address support@digitalstrom.com . I know it took some time, but I had a good contact there with one of the product owner. I have the name, but I do not know if I am allowed to write here.

But he owns a blog https://ds-tools.net/blog/

Perhaps you could contact him. I think they changed the API and forgot to document it.

[ardanedh]

But he owns a blog https://ds-tools.net/blog/

Unfortunately, the mentioned product owner is no longer working for digitalSTROM ...

[ardanedh]

I've now seen the issue mentioned on the digitalSTROM facebook page as well, with no statement from digitalSTROM so far.
Other developers (german forum symcon) are discussing the problem as well.
I still hope digitalSTROM releases a bugfix for the dSS, before changing any binding code ...

[alexf2015]

I can also confirm that the bug occours on my side since I updated digitalstrom server to 1.19.2.
Unfortunately that release is announced as final stabilization release for dss11 series which means there are no plans to provide further updates. Hopefully they will fix the bug introduced with 1.19.2.

A few months ago I reported a bug to digitalstrom caused by a interger overflow. I used a web form to raise my finding:
https://help.digitalstrom.com/hc/de-ch/requests/new
I got feedback quite fast although it seems that the guys there were not expecting reports of software bugs. But finally they fixed it and it took only something about 2 weeks. Maybe that is also an option to get into contact.

[alexf2015]

I checked API docs and I believe the change in general is intentional. Maybe it was a mistake that it was applied now or maybe the API documentation was not updated properly.
But if you have a look at "/json/metering/getAggregatedLatest" you will see that the response should contain both dsuid and dsid while dsid is deprecated. I guess there are plans to remove dsid in general.

[alexf2015]

Feedback from digitalstrom support:

I will discuss this issue with my collegues of our developement and will inform you.
Best regards,
Muharrem Kaya

and second reply

is it possible for you to use "dsuid" (instead of "dsid")?
Best regards,
Muharrem Kaya

So it looks like they do not want to revert that change.

[ardanedh]

So it looks like they do not want to revert that change.

The dSS software version 1.19.2 has been announced as the End of life stabilization release for dSS11-1GB, dSS11-E, dSS IP ... a bold move breaking such a fundamental part with the last release and not being willing to fix it ...

Thanks for getting in contact with digitalSTROM, though!

[alexf2015]

I am also not happy as I own a dSS11-1GB device and I do not want to replace it. Unfortunately I could happen that the API will be changed in future releases in a way that makes it hard to keep the binding backwards compatible.

[ardanedh]

Interesting development in the digitalSTROM server releases. digitalSTROM removed the release 1.19.2 from their download section and recommends version 1.19.1:

Since 1.19.2 introduced an issue with setting the dimming in 300 series it is not available for now. (statement found on faceb@#¼).

I'm genuinely curious if they fix the dSUID/dsid mishap as well.

[alaub81]

hopefully not. I installed today openHAB version 3.3.0.M1 with the fix and everything is working fine since a few hours 🙂

Thanks for fixing it!

[ardanedh]

@alexf2015 's fix is "backwards" compatible, so correcting the dSS side wouldn't do any harm ☺️

[alexf2015]

This is the answer from digitalStrom Support:

Hello,
I have the information that unfortunately it is not planned to revert this change.
Best regards,
Muharrem Kaya

So I do not think that it is planned to provide any further updates/fixes for dSS11 series. If I was affected by the other bug in 1.19.2 I would try to get in contact once again.