Geräte von Technische Alternative mittels CAN over Ethernet (CoE) einbinden
Beschreibung
Das Modul CoE-Knoten (JoTTACoE) stellt eine Instanz zum Senden/Empfangen von Werten an Geräte (z.B. UVR16x2) von Technische Alternative via CAN over Ethernet (CoE) zur Verfügung.
In IP-Symcon gibt es bereits ein integriertes Modul zur Einbindung von solchen Geräten via JSON-API. Dieses hat aber durch Limitierungen der JSON-API diverse Einschränkungen, welche durch das Modul CoE-Knoten (JoTTACoE) umgangen werden können:
Die API erlaubt max. 1 Anfrage pro Minute. Über CoE werden die Werte sofort bei Änderung oder nach einer bestimmten Zeit (kann auf der CMI eingestellt werden) zu IPS übermittelt.
Die API kann Werte von der CMI nur lesen. Über CoE können sämtliche Werte auch geschrieben werden.
Über die API ist der Konfigurations-Aufwand ziemlich gering. Über CoE ist die gesamte Konfiguration etwas komplexer - aber man macht es ja meistens nur einmal
Beide Module lassen sich auch kombinieren. Das integrierte Modul Technische Alternative holt die Daten jede Minute von der CMI ab. Das Modul CoE-Knoten (JoTTACoE) senden die notwendigen Werte (z.B. Schalter, Soll-Temperatur, usw.) an das Endgerät zurück.
Voraussetzungen
IPS 6.0 oder höher
CMI von Technische Alternative
Empfang via CoE: die CoE-Ausgänge auf der CMI müssen entsprechend konfiguriert werden.
Senden via CoE: die CAN-Eingänge auf dem Endgerät müssen konfiguriert werden.
Unterstützte Geräte
Das Modul wird grundsätzlich für eine UVR16x2 programmiert / getestet (Heizungs-Steuerung). Da die CMI von Technische Alternative aber alle Werte (CAN-Bus, DL-Bus, ModBus, SMS) via CoE zur Verfügung stellen kann, ist auch die Steuerung anderer Geräte am CAN-Bus und der Empfang von Daten der anderen CMI-Eingänge möglich.
Installation
Das Modul steht im Module-Store zur Verfügung. Einfach nach CoE-Knoten (JoTTACoE) suchen & installieren.
CMI-IPS
Irgendwie bleiben die kommenden Daten zwischen UDP-Socket und Instanz hängen. Im Debug vom UDP-Socket kommen die Werte noch an aber die Variablen ändern sich nicht.
IPS-CMI
Werte werden einwandfrei an den Regler gesendet.
Wunsch: Die Instanz müsste in regelmäßigen Abständen die Werte senden um ein Timeout am Regler zu verhindern
Zwischen UDP-Socket und Instanz gibt es absichtlich einen Filter, welcher nur Pakete an die Instanz weiterleitet, bei welchen die Werte aus der Instanz-Konfiguration für Remote-CMI übereinstimmen…
Kannst du bitte folgendes prüfen:
Instanz-Konfiguration: IP der CMI & Empfange von Knoten-Nr
CMI COE-Ausgang: Knoten muss „Empfange von Knoten-Nr“ der Instanz entsprechen
Wenn diese Werte übereinstimmen, müsstest du die Weiterverarbeitung der Pakete im Debug der CoE-Instanz sehen…
Sonst bitte einmal einen Printscreen beider Konfigurationen (CMI CoE-Ausgang & Konfiguration CoE-Instanz) und am besten noch einen Debug-Dump aus dem UDP-Socket dazu posten.
Ist bereits auf der ToDo-Liste und kommt demnächst
Habe angedacht, dass dies ein Timer für alle Ausgänge zusammen wird. Aus meiner Sicht macht es keinen Sinn das für jeden Ausgang einzeln zu definieren. Wäre das ok?
Das sieht soweit gut aus.
Verwendest du IPS 6.0? Auf welchem OS läuft IPS bei dir?
Senden kannst du ja, also stimmt die IP der Remote-CMI anscheinend.
Ist im UDP-Socket der Empfangs-Port auf 5441 eingestellt?
Hast du noch einen PrintScreen vom Debug des UDP-Socket?
Hast du irgendwelche Fehlermeldungen im Log?
Sorry für die vielen Fragen, aber bei mir klappt es einwandfrei und ich kann den Fehler im Moment so nicht finden
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?
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.
(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 
