UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Palm_Maniac]

Es war kein hängender Adapter, das Problem war wohl bei Discovergy selbst, denn auch auf der HP wurden keine Daten aktualisiert, obwohl der Zähler fleissig lieferte.

[Palm_Maniac]

Hi,

seit gestern kommen bei mir die Daten weder auf der Discovergy-Seite noch im Adapter in Echtzeit an. Liegt das nur hier bei mir oder kann das noch jemand bei sich beobachten?

[JB_Sullivan]

@Palm_Maniac Discovergy hat eine Wartung und somit verlangsamte Datenübertragung in ihr Portal und somit auch an die API angekündigt. Kein Grund zur Sorge, die Daten kommen "bröckchenweise" wieder an und werden auch wieder nachgeholt.

Gestern war bei mir um 3:00 Uhr Schluss mit Daten und heute sind die Daten von Gestern nachgetragen. Aber auch heute ist seit 8:00 Uhr auch wieder tote Hose.

Das wird sich schon alles wieder beruhigen - also keine Panik.

[Palm_Maniac]

@JB_Sullivan Das habe ich gemerkt und bin durchs Haus gesprintet und habe das Knöpfchen am Zähler betätigt ohne Besserung. ;)

Danke für die Info, es läuft gerade wieder an normal zu laufen. Sieht schon komisch aus, wenn angeblich die Nacht über ein konstanter Verbrauch stattfinden soll und der auch noch doppelt so hoch wie normal. :)

[Webranger]

hallo zusammen.

gerade kam eine email von discovergy.
betrifft das diesen adapter und somit uns?

API-Änderung: Neue, vereinfachte Notation
für RLM-Stromzähler des Fabrikanten EMH.
Auch anwendbar für alle anderen RLM-Zähler

API-Änderung: RLM-Zähler

Sehr geehrte(r) Frau/Herr ,
Heute möchten wir eine Änderung ankündigen, die sich auf die Notationen auswirkt, mit denen die Messwerte einiger RLM-Stromzähler in unserem System gespeichert sind und wie diese über die API abgerufen werden können.

Für alle von dem Fabrikanten EMH hergestellten RLM-Zähler wurden die Felder bisher in OBIS-Notation gespeichert und die Werte auf 1 000 000 Einheiten pro kWh festgelegt. Für alle anderen Zähler verwenden wir im System anstatt OBIS einen menschenlesbaren Namen – energy – und 10 000 000 000 Einheiten pro kWh.

Fortan werden allerdings bei allen neu installierten EMH RLM-Zählern keine OBIS-Notationen mehr verwendet, sondern die Daten mit derselben menschenlesbaren Notation – energy – und mit derselben Skalierung wie bei anderen Zählern gespeichert.

Zur Veranschaulichung: Nehmen wir zum Beispiel an, es wurden 12 kWh von einem RLM-Zähler des Fabrikanten EMH gemessen. Diese Daten sehen derzeit so aus:
Feldname: 1.8.0
Wert: 12 000 000

Nach der Änderung werden die Daten wie folgt aussehen:

Feldname: energy (normalisiert auf denselben Namen wie bei allen anderen Zählern)
Wert: 120 000 000 000 (normalisiert auf den gleichen Faktor wie bei allen anderen Zählern)

Bei Anwendungen, die auf unserer API basieren und Messwerte von EMH RLM-Stromzählern abfragen, müssen diese Felder entsprechend angepasst werden. Obwohl diese Änderung nur die oben erwähnten RLM-Zähler von EMH betrifft, möchten wir auch anderen interessierten Kunden die Möglichkeit bieten, dieses normalisierte Format für alle ihre RLM-Zähler zu übernehmen.

Die Änderung könnte zukünftige Entwicklungen und Integrationen auf Kundenseite erleichtern, indem es nicht mehr notwendig wäre, mit zwei Branchencodes zu arbeiten (einem für RLM-Zähler und einem für SLP-Zähler), sondern alle Daten könnten einheitlich abgerufen werden. Dies ist besonders vorteilhaft für Kunden, die mit der API arbeiten und sowohl über SLP- als auch RLM-Zähler verfügen.

Wollen Sie diese Änderung für Ihre bereits oder künftig installierten RLM-Zähler übernehmen, können Sie sich gerne an Ihren Ansprechpartner bei Discovergy wenden oder einfach eine E-Mail an unseren Vertrieb (vertrieb@discovergy.com) schicken.

Bei Fragen zu den in diesem Artikel beschriebenen Änderungen schicken Sie gerne eine E-Mail an api@discovergy.com. Wir werden uns bemühen, Ihre Frage schnellstmöglich zu beantworten.

Herzliche Grüße
Ihr Discovergy-Team

[JB_Sullivan]

@webranger

das wäre dann ein Thema für @Dutchman

[Dutchman]

@JB_Sullivan @Webranger

hmm ich kan mir nur schwer vorstellen was das fuer Anwender bedeutet allgemein sitzt die logic drin welche der genannt wird.

Es kan passieren das jetzt werte dieses Zählers anders sind als vorher, code technisch ist alles. nach dem ideologie wie beschrieben

[Holger76]

kurze Frage wenn es gestattet ist: Mein Zähler hatte seit März ein DLAN Problem und sendet nun nach 8 Monaten endlcih wieder Daten. Allerdings nur ca 1 Wert pro Minute, auch im Webportal. Gab es da irgend ein Firmware Update, was die Daten drosselt (im April sollte etwas ausgerollt werden, hatte ich gelesen), oder sollte das wie bisher laufen ? Früher war ca alle 3-5 Sekuden ein Wert da..
Oder läuft da ggf. ein Update, was die Daten behindert ?

Der Adapter tut was er soll, danke dafur !

[opossum]

Hallo,
musste heute mein Passwort bei Discovergy ändern. Auf der Website alles ok, kann mich auch mit dem neuen Passwort anmelden. Eine Änderung im Adapter quittiert der Adapter seit dem mit der Farbe "gelb" und zwei Errormeldungen.

Spoiler

[doDiscovergyCall] RequestError: Error: write EPROTO 139774138xxxxxx:error:1409xxxx:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 80

Connection_Failed at meter indication run, check your credentials !

Das Passwort hatte erst Sonderzeichen etc. Habe das nun testhalber mal auf Passwort ohne Sonderzeichen geändert. Aber auch damit bleibt der Adapter gelb. Hat da vielleicht jemand auch diese Probleme?

EDIT: Jetzt ist der Adapter wieder grün, anscheinend hat Discovergy ein wenig gebraucht, das neue Passwort zu akzeptieren.

[dskrt]

Hallo, ist dies die richtige Stelle um am Discovergy Adapter 0.5.8 eine Änderung vorzuschlagen?

Und zwar fehlt ein Timestamp im Objektbaum für die ausgelesenen Werte für 'lastreading'. Der timestamp wird zwar mitgeliefert aber nicht im Objektbaum gespeichert:

{"time":1641879030950,"values":{"power":144620,"power3":86070,"energyOut":292749764000,"power1":13360,"energy":71331567821000,"power2":45190}}

Dieser timestamp ist wichtig da die Discovergy Server manchmal einen Schluckauf haben und dann während Stunden (so wie am 10.1.2022) keine Daten liefern. Nach dem der Schluckauf abgeklungen ist werden die Daten in schneller Reihenfolge nachgeliefert. Ohne diesen timestamp ist dann keine Zuordung der Werte/Zeit mehr möglich. Diese Zuordnung ist sehr wichtig zb bei stündlichen Tarifen von awattar oder tiber.

Wäre es möglich diesen timestamp in den Objektbaum einzufügen ?

Vielen Dank im Voraus

[JB_Sullivan]

Discovergy hat Insolvenz in Selbstverwaltung beantragt

Was auch immer die folgende Nachricht für die Zukunft für uns und unsere Discovergy Zähler und somit den ioBroker Adapter bedeuten mag, vermag ich nicht zu beurteilen, trotzdem möchte ich die Info aus dem Discovergy Forum den ioB Nutzern nicht vorenthalten - sofern ihr diese nicht bereits selber gefunden habt.

Discovergy - Insolvenz in Selbstverwaltung

[Webranger]

@Dutchman Discovergy benennt sich bald um und bekommt auch eine neue url für die Domain, App und api!

Ist das für den Adapter wichtig das er weiter seinen Dienst verrichten kann?

Parallel dazu arbeiten wir an der sukzessiven Anpassung aller Elemente unserer Unternehmensidentität (Website, Energieportal, App, E-Mail-Adressen, Social Media etc.). Durch automatische Updates und Weiterleitungen werden unsere App, unser Portal und weitere Dienste auf das Logo, die Domain und andere Elemente der inexogy Markenauftritts verweisen.

[icebear]

Wie von Inexogy (vormals Discovergy) wurde gestern (04.09.2025) die API von api.discovergy.com auf api.inexogy.com umgestellt.

Seit dem funktioniert der Adapter nicht mehr:

discovergy.0 | 2025-09-04 18:45:25.614 | error | [doDiscovergyCall] StatusCodeError: 401 - "401 Unauthorized: Authorization header missing in HTTP request" -- | -- | -- | -- 
discovergy.0 | 2025-09-04 18:45:25.606 | error | Connection_Failed at meter indication run, check your credentials ! 

Issue wurde hier erstellt

Aktuell ist die Adapter Version 0.5.13 im repo verfügbar.

Auf der github, ist zu sehen das in der main.js der Zugang bereits auf api.inexogy.com geändert wurde, und die Versions Nummer auf 0.6.0 gesetzt wurde, diese Version wurde aber anscheinend nie veröffentlicht.

[deta]

@icebear auf die schnelle kannst du das in der main.js einfach ändern. Und schon gehts wieder.
Habe ich gerade gemacht.

[icebear]

@deta

Danke für den Tipp, hatte ich auch heute morgen schon gemacht.
Ich hab allerdings gleich die ganze main.js ausgetauscht :face_with_rolling_eyes:

[skvarel]

Ich nutze die Version von Github seit fast einem Jahr und hier läuft alles

[skvarel]

Bei mir war die Umstellung aber auch schon im Dezember 2024. Ich hatte dazu ein Issue erstellt und Dutchman hatte es direkt angepasst.

https://github.com/DrozmotiX/ioBroker.discovergy/issues/249

[icebear]

@skvarel said in Test Adaper Discovergy v0.4.x:

Ich nutze die Version von Github seit fast einem Jahr und hier läuft alles

Danke für den Hinweis, hab jetzt dann auch die Version vom Github installiert.

Prinzipiell gehts doch aber auch darum, das wenn die v0.6.0 schon seit fast einem Jahr vorliegt, das die das dann vielleicht auch in das 'latest' oder 'stable' Repository schafft. Für all diejenigen, die halt nicht so experimentierfreudig sind.

Ich hab mal @mcm1957 angeschrieben, ob der Ersteller überhaupt noch tätig ist und was man da machen kann.

[mcm1957]

@skvarel

Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten.

GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird.

Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen.

Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird.

@icebear

Danke dass du Bescheid gegeben hast. Ich hab @Dutchman kontaktiert und er hat einen zügigen Fix / Release zugesagt.

[Dutchman]

@icebear

sorry leute habe das damals gefixt aber total vergessen zu releasen...
Soeben 0.6.0 auf NPM publiziert, sollte morgen in iob sichtbar sein

Bitte testen, wen das laeuft geht es innerhalb 1-2 tage nach stable