Replies: 4 comments 32 replies
-
|
Moin @Dreman65! Top Arbeit. Ich schaue mir mal Richtung nächste/übernächste Woche deine neuen Datenpunkte an und vergleiche die mit meiner Anlage. Bin aktuell noch im Urlaub und will dann meine open3e Installation umziehen und mal mit der iobroker Integration arbeiten bzw rumprobieren. Muss dafür aber erst ne neue iobroker VM in Proxmox aufsetzen und als Slave zu meiner Haupt-iobroker Instanz hinzufügen. Hat auch andere Gründe und muss für den HB Daten loggen. Hab Drucksprünge von 0,9-1,6 bar im Heizkreis und will mal schauen wann welcher Druck anliegt in welchem Zustand. Ist mit nem iobroker halt relativ easy über den History Adapter. Aber ist nen anderen Thema und ich schweife ab. Denke @philippoo66 wird da auch Interesse an den neuen Datenpunkten haben. Hab da mit ihm damals auch alles viel durchgearbeitet, aber die Integration ist nicht so einfach wegen der unterschiedlichen Anlagenkonfigurationen und das die Datenpunkte unterschiedlich sind. |
Beta Was this translation helpful? Give feedback.
-
|
Moinsen, hab mal durchgeschaut. Die RoomOne... Etc. Datensätze sehen gut aus. Passen mit meiner Anlage und den Räumen zusammen beim groben drüber schauen. Die könnten denke übernommen werden. Diskrepanz bei den Zigbee Devices ist nunja, nen Problem. Aber glaube da wird es nie ne saubere Lösung für geben. @MyHomeMyData wie übersetzt du die Datapoints.py ins json Format für e3oncan? Hast du da nen Wrapper der das übersetzt oder schreibst du das händisch? Hab e3oncan jetzt am Laufen und per ChatGPT (Schande über mein Haupt) meine Zigbee Device Felder übersetzt. Wann greift die ausgetauschte json in opt/iobroker/node... /e3oncan/lib? Nach Neustart vom Pi? Adapterneustart? Rescan der Datenpunkte in den Instanzsettings? Bin da noch nicht ganz hinter gestiegen. Dann kann ich auch da noch weiter gucken. |
Beta Was this translation helpful? Give feedback.
-
|
@Backes89 Das Datapoints.json wird mit dem Tool |
Beta Was this translation helpful? Give feedback.
-
|
Alles klar. Dann setze ich das morgen mal wieder zurück 😅 Den Fehler mit dem leeren String von @Dreman65 im Eingangspost, wenn beim Namen zum Sensor zwei Nullen vorne sind kann ich übrigens bestätigen. |
Beta Was this translation helpful? Give feedback.
-
|
@MyHomeMyData Wie sieht das denn mit der enums.js aus? Die hab ich ebenfalls erweitert bzw. gibt es für die Thermostate und Co neue Felder. Gibt es dafür auch nen Datenpunkt innerhalb der Objektstruktur damit ich die neuen Sachen mit laden kann?
|
Beta Was this translation helpful? Give feedback.
-
|
@Backes89 Nein, dafür gibt es derzeit nur den Weg über ein Update der Version. Die gemeinsame Datenbasis für open3e, E3onCAN und ioBroker.e3oncan ist der Branch develop im open3e-Repository. Deshalb bitte:
|
Beta Was this translation helpful? Give feedback.
-
|
Weiterführung der Diskussion wegen Unstimmigkeiten, siehe hier. Nach meine Analyse unterscheiden sich die Definitionen von 2086 von @Backes89 und in e3oncan/open3e:
Haben wir es mit verschiedenen ZigBee-Geräten zu tun oder ist die open3e-Tabelle nicht korrekt? |
Beta Was this translation helpful? Give feedback.
-
|
Ich kopiere das jetzt einmal schnell aus ClaudeCode raus mit nem Datensatz von mir. Bin aufm Sprung ins Auto. Die eNums müsste ich später mal noch genau prüfen und ne Rückmeldung geben. Datenpunkt
|
Beta Was this translation helpful? Give feedback.
-
|
und hier noch das mit eNums. Die enums.js hab ich hier lokal im vscode. Ob ich die auch shcon irgendwo hier hab kann ich gerade spontan nicht sagen. Rechtschreibfehler hat auch gerade ClaudeCode gefunden. Der war mir garnicht aufgefallen. Datenpunkt
|
| Feld | ID | Aufgelöst zu |
|---|---|---|
| ViCareDevice | 1 | Climate sensor |
| ViCareThermostaticRadiatorValveDisplayMode | 0 | Standard |
| ViCareThermostaticRadiatorValveChildLock | 0 | Not Active |
Nur ViCareDeviceType → ViCareDeviceTypes ist betroffen. Die anderen beiden müssten eigentlich funktionieren — falls dort trotzdem „Enum not found" gemeldet wird, lohnt ein Blick auf Groß-/Kleinschreibung oder den Lookup-Mechanismus.
Enum-Definitionen aus enums.js
ViCareDeviceTypes: { 1: "Climate sensor", 2: "Thermostatic radiator valve", 3: "Distributor underfloor heating", 4: "Actuator underfloor heating - powerless closed", 5: "Actuator underfloor heating - powerless opened", 7: "Repeater" },ViCareThermostaticRadiatorValveDisplayModeState: {
0: 'Standard',
1: 'Turned',
},ViCareThermostaticRadiatorValveChildLockState: {
0: 'Not Active',
1: 'Active',
},
CurrentWorkingModeLevels: {
0: 'Unkown1',
1: 'Uknown2',
64: 'Unkown3',
100: 'Unknown4'
},
Wichtige Erkenntnis: Der Codec ist polymorph
ViCareDevice = 1 löst zu "Climate sensor" auf — nicht zu „Thermostatic radiator valve" (ID 2), wie man angesichts des Datenpunkt-Namens und der ZigBee-MAC im Trailer vermuten könnte.
Damit ergeben die übrigen Werte plötzlich Sinn:
- Ein Klima-Sensor liefert Temperatur (22.3 °C) und Luftfeuchte (48 %) — genau das, was ein Klima-Sensor tut ✓
- Felder wie
TemperatureByHandundChildLocksind beim Klima-Sensor logischerweise0/inaktiv, weil für diesen Geräte-Typ nicht relevant
Konsequenz: Die Struktur ZigBeeOneDeviceCurrentValues wird für mehrere ZigBee-Gerätetypen (TRVs, Klima-Sensoren, Repeater, Unterflurheizungs-Aktoren …) verwendet. Welche Felder belegt/sinnvoll sind, hängt vom ViCareDevice-Typ ab. Der TRV-spezifische Naming-Präfix (ViCareThermostaticRadiatorValve…) bei DisplayMode/ChildLock/TemperatureByHand ist daher etwas irreführend — für andere Gerätetypen sind diese Felder schlicht ungenutzt.
Offener Punkt: CurrentWorkingModeLevels
Die Liste enthält nur Platzhalter:
CurrentWorkingModeLevels: {
0: 'Unkown1',
1: 'Uknown2', // sic — Tippfehler
64: 'Unkown3', // sic
100: 'Unknown4'
}
Im Decoder-Output erscheint dennoch CurrentWorkingMode = 0 → StandBy — das deutet darauf hin, dass entweder eine andere Enum-Quelle verwendet wurde (z.B. die generische States-Liste, wo 6: 'Standby' steht) oder eine ältere Version. Hier ist noch echte Reverse-Engineering-Arbeit nötig, um die Werte 0, 1, 64, 100 für ZigBee-Geräte sinnvoll zu benennen.
Empfohlene Fixes
- Codec-Definition korrigieren:
listStr: "ViCareDeviceType"→"ViCareDeviceTypes"(Plural). CurrentWorkingModeLevelsrecherchieren und die Platzhalter durch echte Bezeichnungen ersetzen (inkl. Tippfehler-FixUknown2→Unknown2).- Optional: Die TRV-spezifischen Feldnamen (
ViCareThermostaticRadiatorValve…) generischer fassen oder per Doku klarstellen, dass sie nur fürViCareDevice = 2(TRV) bedeutungsvoll sind.
Beta Was this translation helpful? Give feedback.
-
|
Für die CurrentWorkingModeLevels gibt's auch schon mehr. Kühlen sollte zeitnah rauszubekommen sein. Temperaturen draußen passen ja. Schaue später mal im History Adapter vom e3oncan ob ich was finde. |
Beta Was this translation helpful? Give feedback.
-
|
Vielen Dank für die detaillierte Analyse, @Backes89, und für die ergänzenden Testergebnisse! Fazit nach Auswertung: Definition B ist korrekt – die bisherige open3e-Definition ist fehlerhaft. Unabhängige Bestätigung durch ViGuide-Demo-App In der öffentlich zugänglichen ViGuide-Demo-App von Viessmann findet sich das Feature Analyse der Struktur Der Datenpunkt Korrekte Struktur (mit open3e-Feldnamen) O3EComplexType(68, "ZigBeeOneDeviceCurrentValues", [
RawCodec(2, "Unknown1"),
O3EInt8(1, "BatteryLevel"),
RawCodec(37, "Unknown2"), # war 38 – 1 Byte zu lang
O3EInt8(1, "SignalLevel", scale=2.55), # neu: LQI bei Offset 0x28
O3EEnum(1, "ViCareDevice", "ViCareDeviceTypes"),
O3EInt8(1, "ActualTemperature", scale=10),
O3EEnum(1, "CurrentWorkingMode", "CurrentWorkingModeLevels"),
O3EInt8(1, "Humidity"), # neu: bei Offset 0x2C
RawCodec(3, "Unknown3"), # war 4 – 1 Byte zu lang
O3EEnum(1, "DeviceDisplayTurned", "DeviceDisplayModeStates"),
RawCodec(5, "Unknown4"),
O3EEnum(1, "DeviceChildLockActive", "DeviceChildLockStates"),
O3EInt8(1, "DeviceTemperatureSetpoint"),
RawCodec(12, "Unknown5")], acc="ro")
# Summe: 2+1+37+1+1+1+1+1+3+1+5+1+1+12 = 68 ✓Zuordnung der Enum-Namen (Backes89 → open3e)
Geplante Änderungen in open3e
Zum Thema Kühlen: Falls sich aus dem e3oncan History Adapter brauchbare Werte ergeben, können wir |
Beta Was this translation helpful? Give feedback.
-
|
@Dreman65 Das Variantenkonzept erlaubt mehrere Varianten der selben DID mit verschiedenen Längen. Wir können also die 57-Byte-Variante von 2086 einfach zusätzlich aufnehmen. Beim nächsten depictSystem bzw. e3oncan-Upgrade oder Datenpunktscan wird diese Variante dann übernommen. Ich mach mal einen Vorschlag incl. der neuen Erkenntnisse. Die Variante haben wir beim letzten Update leider übersehen. Dass Viessmann solchen Blödsinn macht, scheint ja der Normalfall zu sein. 100 => Kühlen: Nehme ich auf. Bitte um Info, falls es sich nicht bestätigt. |
Beta Was this translation helpful? Give feedback.
-
Die hier diskutierten Änderungen bringe ich dann mit 1.0.3 |
Beta Was this translation helpful? Give feedback.
-
Vlt macht es Sinn da aber auch das erste Byte auf Unknow zu setzen wie hier. Der Name geht ja auch erst danach wirklich los.
|
Beta Was this translation helpful? Give feedback.
-
|
Und in den ZigbeeProperties fehlt das "s" hinten ViCareDeviceType für die enums-Liste. Die löst er nicht auf, weil er die natürlich nicht findet aufgrund fehlernder Schreibweise. Kann ich dir irgendwie helfen indem ich einmal alle relevanten Datenpunkte sauber mit den Codecs hier rein packe mit meinen Erkenntnissen? |
Beta Was this translation helpful? Give feedback.
-
|
@Backes89 Ja, das fehlende "s" hab ich schon drin. Ein führendes Byte als RawCodec einzufügen, ist der bessere Weg. Mach ich so. |
Beta Was this translation helpful? Give feedback.
-
|
Ich habe die in dieser Diskussion erarbeiteten Vorschläge nun in den Branch Umsetzung der abgestimmten Vorschläge
Hinweis zu DID 2084Für die ZigBee Property DIDs (2084 ff.) gibt es zwei leicht abweichende Vorschläge:
Ich habe die Variante von Backes89 umgesetzt, da das Feld dort explizit als |
Beta Was this translation helpful? Give feedback.
-
|
moin ihr! uih, ihr seid ja richtig fleissig und produktiv- super!! Weil das alles für mich nur ein Gedankenkonstrukt ist (ohne Zielsystem), hab ich immer mehr Probleme, euch überhaupt zu folgen... bezieht sich das "ist irgendwie ein bisschen kompliziert geworden mit den varianten Dids." nur auf den Adapter (wegen userSpecificDids) oder gilt das auch für open3e? (natürlich hat es die Komplexität gesteigert, aber das userSpecificDids Issue gibt es doch da nicht, weil nicht vorgesehen, oder?) |
Beta Was this translation helpful? Give feedback.
-
|
@philippoo66 Hallo Phil, die Aussage bezieht sich nur auf ioBroker. Für open3e sehe ich da kein Problem. Hab auch eine Frage: Bei den letzten Datenpunkt-Updates bin ich darüber gestolpert, dass einige "UnknownX" nicht mit RawCodec versehen waren. Das habe ich mit dem aktuellen PR nun durchgängig angepasst, also auch bei Datenpunkten, die schon länger einen anderen Codec für "Unknown" hatten. Details siehe hier. Passt so, oder? Ich musste dann auch Unit- und Integrationstests ein wenig anpassen, aber mit Claude Code war das schnell erledigt. |
Beta Was this translation helpful? Give feedback.
-
|
@MyHomeMyData Hallo Jürgen, wahrscheinlich sollte ich mich mal intensiver mit den Varianten Dids auseinandersetzen, aber eigentlich funktioniert bereits jetzt alles so, wie es für mich passt. Ich weiß allerdings nicht warum :-). Hier am Beispiel von Parameter 2084, Gerät 0x6e0:
Soweit funktioniert aus meiner Sicht alles wie gewünscht, ich weiß, wie schon gesagt, nur nicht warum :-). |
Beta Was this translation helpful? Give feedback.
-
|
@Dreman65 Hallo Manfred, für 2084 liegen die Dinge recht einfach, weil es nur die common-Definition gibt, keine Varianten. Wenn Du bei so einem Datenpunkt eine specific-Version erzeugst, gewinnt die immer. Die Komplexität entsteht nur bei Dids, die Einträge in der Open3EdatapointsVariants.py haben (bzw. in der didsE3var.json). |
Beta Was this translation helpful? Give feedback.
-
@MyHomeMyData hm, ich hab da keinerlei Erinnerung, wie das da rein gekommen war. Wahrscheinlich hatte derjenige es einfach erstmal als Zahlenwert dargestellt, um zu schauen, ob sich dann irgendwas erkennen lässt. Und dann war es halt so stehen geblieben. Da es ja unknown ist, ob es ein Zahlenwert (und wenn ja, ob/wie skaliert) oder irgendwas andres ist, ist Raw wahrscheilich die bessere Wahl. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Anbei meine Erkenntnisse zur Einbindung des Viessmann Klimasensors (ohne zusätzliches Viessmann Thermostatventil) in die Vitodens 300-W-B3HG in das Gerät 0x6e0 (SMARTROOMCONTROL). Grundlage dafür sind die von @Backes89 an der Vitocal 252 gefundenen Parameter/Werte (siehe WIKI 070).
1884 : O3EComplexType(84, "RoomOneProperty", [RawCodec(1,“unknown“),O3EUtf8(39, "roomname"), RawCodec(3, "unknown1"), O3EInt8(1, "roomtype"), RawCodec(1, "unknown2"), O3EInt8(1, "temperature control"), RawCodec(29, "unknown3"), O3EInt8(1, "window open detection active"), RawCodec(8,"unknown4")]),2084 : O3EComplexType(84, "ZigBeeOneDeviceProperty", [RawCodec(8, "serialnumber"), RawCodec(1, "serialnumberpostfix"), O3EUtf8(39, "devicename"), RawCodec(36, "unknown")]),1886: O3EComplexType(46, "RoomOneCurrentValues",[O3EInt16(2, "ActualTemp", signed=True), O3EInt16(2, "MinimumTemp", signed=True), O3EInt16(2, "MaximumTemp", signed=True), O3EInt16(2, "AverageTemp", signed=True), O3EByteVal(1, "unknown1"), O3EInt8(1, "ActualHumidity"), O3EInt8(1, "MinimumHumidity"), O3EInt8(1, "MaximumHumidity"), O3EInt8(1, "AverageHumidity"), O3EByteVal(1, "unknown2"),RawCodec(32,"unknown3")]),2086 : O3EComplexType(57, "ZigBeeOneDeviceCurrentValues", [RawCodec(2, "unknown1"), O3EByteVal(1, "Battery Level"), RawCodec(37, "unknown2"), O3EByteVal(1, "Signal Level"), O3EByteVal(1, "Valve Type"), O3EInt16(2, "Temperature"),O3EInt8(1, "Humidity"), RawCodec(12, "unknown3")]),Achtung: 100% Signalstärke entspricht dabei einem Hex-Wert von FF!
Fazit: Die wesentlichen Parameter sind abrufbar aber: es gibt noch viele unknowns :-).
@MyHomeMyData Bei den ganzen Versuchen ist mir noch folgendes aufgefallen: liest man einen Textwert z.B. die ersten 40 Bytes in DID 1884
00576f686e7a696d6d65720000000000000000000000000000000000000000000000000000000000mit dem Encoder O3EUtf8 wie in DID 1884 und dieser Text startet mit Nullen, dann liefert open3E den String "Wohnzimmer", e3oncan jedoch nur """". Nur als Hinweis.
Update zu Punkt 2) am 14.05.25:
2084 : O3EComplexType(84, "ZigBeeOneDeviceProperty", [RawCodec(8, "serialnumber"), RawCodec(1, "serialnumberpostfix"), O3EUtf8(39, "devicename"), RawCodec(2, "unknown1"), O3ESoftVers(7, "Firmware-Version"), RawCodec(9, "unknown2"), O3EUtf8(16, "VIN"), RawCodec(2, "unknown3")]),Update zu Punkt 3) am 17.07.2025
Meine ursprünglich als 'AverageTemp' und 'AverageHumidity' interpretierten Werte sind zwar Temperatur- und Humidity-Werte, sind aber keine Mittelwerte. Da alle meine Interpretationsversuche bisher negativ waren, korrigiere ich zu 'unknown':
1886: O3EComplexType(46, "RoomOneCurrentValues",[O3EInt16(2, "ActualTemp", signed=True), O3EInt16(2, "MinimumTemp", signed=True), O3EInt16(2, "MaximumTemp", signed=True), O3EInt16(2, "unknown1", signed=True), O3EByteVal(1, "unknown2"), O3EInt8(1, "ActualHumidity"), O3EInt8(1, "MinimumHumidity"), O3EInt8(1, "MaximumHumidity"), O3EInt8(1, "unknown3"), O3EByteVal(1, "unknown4"),RawCodec(32,"unknown5")]),Beta Was this translation helpful? Give feedback.
All reactions