IP-Symcon 6.0, Raspberry Pi (armhf), 28.08.2021, 883beea87a99
Am UDP-Socket kommen die Daten an:
Keine Fehler im LOG.
Die Instanz habe ich auch schon neu angelegt.
IP-Symcon 6.0, Raspberry Pi (armhf), 28.08.2021, 883beea87a99
Am UDP-Socket kommen die Daten an:
Keine Fehler im LOG.
Die Instanz habe ich auch schon neu angelegt.
Gemäss deinem UDP-DebugLog sendet deine CMI einen digitalen Wert von Knoten 30 Netzwerkausgang 1 (1E 00 01 …) und einen analogen Wert von Knoten 30 Netzwerkausgang 1 (1E 01 45 00 …) und das alle Minuten (der Wert erhöht sich laufend). Ist das korrekt?
IP & Port deiner CMI stimmen mit der Konfiguration überein.
Da passiert vermutlich ein Fehler beim Setzten des Filters welcher wohl OS abhängig ist…
Kannst du einmal das Instanz-Debug laufen lassen und in der Instanz-Konfiguration den Wert „Eigene Knoten-Nr“ ändern (alles andere bitte so belassen) und das mit Apply Changes speichern. Im Debug-Log müsste dann ein Eintrag mit dem neuen Filter auftauchen (Set ReceivDataFilter to). Kannst du mir davon einen PrintScreen senden?
Ich schaue schon mal ob ich den Fehler sonst finde…
Danke für den PrintScreen. Habe den Fehler gesehen - oder es wenigstens gemeint (ist schon etwas spät
). Ev. werden die Daten im JSON andersherum angezeigt als bei mir (OS abhängig?). Bei mir kommt ClientIP und ClientPort nach Buffer. Dann würde der Filter nicht greifen. Vielleicht ist es auch sonst ein Fehler im Filter
Habe nun eine Option in der Instanz-Konfiguration eingebaut, welche es erlaubt, den Filter zu deaktivieren. Die neuste BETA findest du im Store.
Kannst du bitte einmal updaten und danach die Option aktivieren? Im Debug-Log solltest du dann folgenden Eintrag kriegen: Set ReceiveDataFilter to .*
Damit müssten die Daten schon einmal ankommen. Bitte anschliessend nochmals einen Debug-Log PrintScreen senden, damit ich das mit dem Filter prüfen kann…
PS: Das Feld Empfange von Knoten-Nr verhält sich beim Laden/Speichern der Konfiguration noch nicht korrekt mit der neuen Option (müsste (de)aktiviert sein, wie wenn die Option geändert wird). Da bin ich noch am suchen…
Danke, jetzt habe ich’s gefunden
Der Filter wird bei dir für den Buffer auf \u001e gesetzt, der UDP-Socket hat aber im JSON \u001E (Gross-/Kleinschreibung des E). Der Unterschied entsteht wohl bei der JSON-Codierung beim Erstellen des Filters…
Werde versuchen das im Verlauf der nächsten Woche zu fixen…
Daten müssten jetzt aber mit dem deaktivieren Filter korrekt ankommen?
Guten Morgen.
Die Daten kommen jetzt wie sie sollen.
Nur kein Stress.
Habe soeben die Version 0.3 BETA im Store veröffentlich.
Damit sollte das Problem mit dem Filter behoben sein (@Bussard013 - kannst du das gelegentlich testen und ein Feedback geben?)
Zusätzlich wurde ein Timer eingebaut, welcher nun alle Ausgänge regelmässig an die Regler sendet. Damit sollte auf dem Regler kein Timeout mehr auftreten und wenn doch, dann „klemmt“ irgendwo etwas.
Weitere Änderungen und neue Instanz-Funktionen siehe Dokumentation.
Hallo,
heute habe ich mal wieder Zeit zum Testen.
Grundsätzlich scheint das Modul fehlerfrei zu funktionieren. Vielen Dank.
„Empfange alle Daten“ habe ich wieder deaktiviert.
Einige Fragen hätte ich aber:
In welchen Abständen wird in IPS die Daten empfangen wenn der CMI jede Sekunde sendet?
Im Moment habe ich noch das Problem einen Wert (z.B. die Ladepumpengeschwindigkeit vom Fröling) in die Variable A2 zuschreiben. Ich verwendete Event bring ich nicht zum Laufen:
Im CMI wird jetzt 2 CAN-Geräte (30 und 31) obwohl die 31 nicht mehr vorhanden ist angezeigt.
Gruß Christian
Hallo Christian,
Danke fürs Feedback.
Die Daten werden von der CMI per UDP an IPS gesendet und von dort sofort an die Instanz weitergeleitet und verarbeitet. Wenn du jede Sekunde sendest, weiss ich nicht, ob die Systeme (CMI & IPS) damit dauernd klarkommen. Wenn die nebenbei noch andere Dinge verarbeiten, wäre es möglich, dass zwischendurch etwas „verloren geht“. Diese Erfahrung müssen wir wohl erst noch sammeln Seitens Modul gibt es theoretisch keine Einschränkung…
Was macht das Debug-Log? Werden die Werte da verarbeitet und gesendet?
Hast du die Variable A2 als Eingang/Ausgang oder nur als Ausgang definiert?
Wenn Eingang/Ausgang, dann wird der Wert gesendet, aber die Variable erst aktualisiert, wenn die CMI den Wert wieder zurück sendest. Dazu müsstest du auf dem Regler etwas programmieren, das den CAN-Eingang wieder auf den CAN-Ausgang zurück schreibt.
Nach einem Neustart der CMI sollten alle CoE-Geräte verschwinden und dort erst wieder auftauchen, wenn sie auch etwas senden.
Ich wollte ursprünglich einfach schauen ob es geht, mit dem Ziel meine Hz-Steuerung via IPS zu regeln. In der Theorie scheint das nun zu klappen Wenn ich jetzt keine Schnitzer mehr finde, werde ich das Modul demnächst als offiziellen Release im Store einstellen. Dann muss ich zuerst die Steuerung auf dem Regler umprogrammieren, damit ich das Ganze auch sinnvoll integrieren kann (schon wieder ein Wochenende verplant
). Die Erfahrung kommt also auch bei mir erst mit der Zeit und wir dann wohl auch noch zu Optimierungen am Modul führen.
Daher einfach her mit allen euren Erfahrungen (positiv oder negativ) und Wünschen. Ich schaue dann einmal, was sich machen lässt…
Hallo zusammen,
ich weiss nicht, ob ich hier richtig bin, aber meine Suche hat nicht so wirklich brauchbare Ergebnisse zu meiner Frage gebracht.
Diese ist:
Ich habe von TA eine Frischwasserstation (Friwa3WP), deren Werte ich mit IPS auslesen möchte. Ich habe aber keine UVR oder sonstwas von TA. Genügt es daher, den DL-Bus der Frischwasserstation mit dem DL-Eingang der (noch zu erwerbenden) CMI zu verbinden und IPS kann dann mit diesem CoE-Knoten (JoTTACoE) die Daten direkt auslesen und in den IPS-Verzeichnisbaum schreiben?
LG
Jörg
Hallo d-fens,
das Auslesen der Daten über eine CMI sollte möglich sein. Du kannst auf der CMI direkt Daten ab DL-Bus einlesen und diese dann von dort mittels CoE an IPS weitersenden. So kann ich es auf meiner CMI wenigstens zusammenkonfigurieren, obwohl ich keinen DL-Bus dran habe.
Ob du aber auch umgekehrt Daten zurückschreiben könntest, weiss ich nicht. Das funktioniert vermutlich nur via CAN-Bus (war ja aber auch nicht deine Frage ).
Für deine Anwendung (nur lesen) würde aber ev. auch bereits das Standard-CMI-Modul von IPS ausreichen. Am besten einfach beides ausprobieren und das Ergebnis hier mitteilen
Gruss aus der Schweiz
jotata
Hallo,
danke für die prompte Antwort.
Ich hatte tatsächlich noch gar nicht nachgesehen, dass IPS auch TA-Equipment unterstützt. Aber ich finde da auch nur UVRs und andere Dinge, aber keine Frischwasserstation. Schreiben würde ich (vorerst) auch nicht wollen, sondern nur Werte lesen, um die fürs warme Wasser aufgewendete Energie zu erfassen. Sonst ginge das nur mit einem externen Wärmemengenzähler.
Aber da werde ich nach der Installation der Friwa mal so eine CMI-Box bestellen und testen. Schlimmstenfalls muss ich sie halt wieder zurücksenden.
LG
Jörg
Vielen Dank für das Modul, ich empfange bereits Daten über vom CMI.
Ich Frage den Heizstab ab und erhalte am CMI z.B. einen Wert von 1.2 KW.
In IP-Symcon kommt der Wert 0.12 rein und wir so in die Variable geschrieben.
Ich habe mir die Info unter COE-Datenübermittlung bezüglich der Kommaverschiebung durchgelesen. Da der Wert bereits mit 0.12 reinkommt, bringt mir auch eine Kommaverschiebung nichts, wenn ich es richtig verstehe, oder?
Hat jemand eine Idee wie ich die 1,2 KW in die Variable bekomme. Aktuell stehen dort 0,12 KW.
Hallo Daste
Das scheint ein Bug zu sein (danke fürs finden ).
Anscheinend rundet TA die 2 Nachkommastellen auf den Reglern bei der Übertragung via CAN-Bus auf 1 Nachkommastelle auf/ab und überträgt dann nur noch eine Stelle (mindestens bei „Leistung kW“ - die Anderen muss ich noch prüfen). Leider sind die Nachkommastellen der Units nicht (öffentlich) dokumentiert und ich bin da bisher immer von 2 Nachkommastellen ausgegangen…
Ich kann den Fehler aber bei mir reproduzieren und werde das entsprechend im nächsten Update fixen. Bis dahin kannst du dir auch einen manuellen fix machen, wenn du die folgende Zeile in der Datei „MODUL-PFAD\JoTTACoE\units.json“ anpasst:
{"UnitID":10,"Name":"Leistung","Suffix":"kW","Decimals":2}, //BUG
{"UnitID":10,"Name":"Leistung","Suffix":"kW","Decimals":1}, //FIXED
Grüsse aus der Schweiz
jotata
Respekt! Vielen Dank für die schnelle Rückmeldung und den Workaround bis das Problem gefixt ist.
Mit so einer schnellen Antwort hätte ich nicht gerechnet.
Ich habe jetzt meinen ersten digitalen Ausgang angelegt im Modul und auch auf meiner 16x2 Steuerung, hier funktioniert der Übertrag der Info von IPS zum CMI /16x2 noch nicht.
Vielleicht fällt euch ein Fehler auf den Screenshots auf.
Du musst den Digitalen Ausgang in IPS entweder als „Ausgang“ oder als „Eingang / Ausgang“ konfigurieren. Im Moment hast du nur die Variable aktiviert. Dadurch kannst du sie aber noch nicht senden.
Details zu den Unterschieden findest du in der Doku unter Konfiguration der Instanz → Analoge/Digitale Variablen → Variable
Da hast du natürlich recht, vor lauter rumprobiererei gar nicht gesehen das er nur auf „Aktiviert“ und nicht auf „Ausgang“ steht.
Umgestellt und schon hat es funktioniert.
Hallo zusammen,
nach langer Suche bin ich auf diese geniale Modul gestoßen um meinen TA-Regel komfortabel auszulesen. Vielen Dank dafür schon mal.
Ein Problem habe ich aber noch, sobald ich im COE-Knoten „Empfange alle Daten“ deaktiviere kommt bei der Instanz nur noch Warte auf Daten und sie geht nicht mehr Aktiv.
Gehe ich in den Debug von der UDP kommt die korrekte Knoten Nummer auch an die ich in der CMI bei Den COE hinterlegt habe.
Weiter oben in dem Beitrag habe ich gelesen das es Anfangs damit Probleme gab, deshalb habe ich die BETA Version installiert.
Ist die Option „Empfange alle Daten“ aktiviert funktioniert alles tadellos .
Vielen Dank für die Hilfe im Voraus
Hallo @rene2411,
kann es sein, dass auf deiner CMI Firmware 1.39 oder neuer isntalliert ist?
Bei mir hat es bisher funktioniert (1.383). Habe heute meine CMI auf 1.40 aktualisiert und habe nun dasselbe Problem wie du. Gemäss Changelog von 1.39 wurden Fehler im CoE-Sendeverfahren behoben…
Muss einmal schauen, was da geändert wurde - wird aber Wochenende…
Gruss
jotata