ESP8266 KNX mit ETS

[richardpub]

Da ich etwas verzweifelt war, nahm ich mir eine Woche Pause, um dieses Projekt, meine eigenen knxprod-Dateien zu erstellen, ruhen zu lassen.
Hat jemals jemand tatsächlich eine der .XML-Dateien von Thelsing in seinen "KNX" Github-Beispielen verwendet, um sie mit der Createknxprod-Software in eine .knxprod-Datei umzuwandeln?
(der Import der knxprod-Dateien der Beispiele ist in der ETS einwandfrei lauffähig). Meine ETS5-Version ist "5.6.241.33672".

Ich glaube, ich liege falsch bei der Verwendung der Createknxprod-Software, um den .xml-Teil der Beispieldatei von einer ETS4 mit einem Projekt 11 in eine ETS5 mit einem Projekt 14 umzuwandeln.
Derzeit ändere ich diese Daten in der .xml-Datei, um sie zu transformieren, aber vielleicht muss die Änderung in der Createknxprod-Software vor der Kompilierung vorgenommen werden, oder ich habe im Grafikteil der Createknxprod-Software vergessen, etwas einzugeben.
Ich habe viele Methoden ausprobiert, aber keine hat mir richtige Ergebnisse geliefert.
Der letzte Versuch mit Projekt 20 gibt diesen Fehler:

21112812271625602917691266.gif

Kann mir jemand helfen, ich komme im Voraus echt nicht durch, danke

[richardpub]

Nach dem Update auf die ETS5-Version steht schließlich "5.7.6".

Ich habe es endlich geschafft, mit Createknxprod eine funktionierende .knxprod-Datei zu generieren.

Im .xml Teil der Beispieldatei habe ich eine ETS5 "Projekt 20" eingetragen.
Im grafischen Teil der Createknxprod-Software habe ich die Seriennummer und verschiedene Felder ausgefüllt, die ich auf 0 belassen hatte.

Ich kann endlich mein Wetterprojekt und die Salzanalyse im Schwimmbad voranbringen?

Grüße

[philipp900]

Vielen Dank für das super Projekt.
Ich habe es inzwischen schon auf 3 Geräten mit ESP32 und ESP8266 erfolgreich im Einsatz.

Lediglich bei den DPTs und Convertern musste ich noch ein paar Dinge anpassen.

Hast du eine Möglichkeit vorgesehen im Code zu prüfen ob die richtige Applikation geladen wurde?
Ich habe mir jetzt beholfen in dem ich die Zahl an groupobjects abfrage bevor ich meine Applikation ausführe.

[richardpub]

Welchen Antrag hast du bei der esp . gestellt?
Ich für meinen Teil würde auch gerne einen Test mit dem sonoff R2 Basic machen
Hast du diese Lösung schon realisiert ???
Welche 3 Bewerbungen hast du gemacht??

[henfri]

Hello,

Google translate does not really translate well your message.
If you can, it is better to post in English, I think.

[thewhobox]

Hast du eine Möglichkeit vorgesehen im Code zu prüfen ob die richtige Applikation geladen wurde?

Das ist nicht die Aufgabe des Stacks.
Solche Sachen gehören in die Ladeprozedur in der Apllikation.
Ein Beispiel wie KNX Virtual das macht ist in Post #1002
Oder über den PID-Hardware Type 0,17

[philipp900]

Mir ist schon klar dass die Prüfung nicht Aufgabe des Stacks sein soll.
Meine Frage war eher dahingehend, ob der Stack eine Funktion bietet mit der ich in meiner Applikation einen Wert abfragen kann der in der knxprod fix hinterlegt ist.
Jede knxprod hat ja z.B. auch eine Versionsnummer und einen Fingerprint.

Wie löst du das thewhobox

[thewhobox]

Die Kommunikation ist Unidirektional.
Es gibt keine Verbindung von Stack zur Ladeprozedur oder anderen Werten in der knxprod.
"<LdCtrlCompareProp InlineData="00FA020723" ObjIdx="4" PropId="13">"
In dieser Property ist ja die Version der Applikation gespeichert (00FA Hersteller, 0207 Applikationsnummer, 23 Version). Dieser sollte je nach Maskversion auch am Ende der Programmierung beschrieben werden.
Eine 100% abfrage, gibt es aber nicht.

Du kannst aber natürlich einen Dummy Parameter anzeigen lassen, der Byte x auf einen Bestimmten Wert stellt.
Und nur wenn der Wert übereinstimmt, lässt dein Programm laufen.
(Aber auch hier keine 100% Sicherheit)

[mumpf]

Hi Mike,

anscheinend weißt Du, was die obige Zeile bzw. das xml im Post 1002 macht. Könntest Du das mal erklären? Irgendwie muss man doch in der Firmware auf eine falsche Product-DB reagieren. Das xml aus Post 1002 sieht aber so aus, als ob die ETS-Applikation darauf reagiert.

Du kannst aber natürlich einen Dummy Parameter anzeigen lassen, der Byte x auf einen Bestimmten Wert stellt.
Und nur wenn der Wert übereinstimmt, lässt dein Programm laufen.

Das würde ich immerhin schaffen. Ich würde nur gerne verstehen, wie Dein Vorschlag funktioniert. Es sind ja 2 Sachen zu erreichen:

• Die ETS meldet, dass die Firmware nicht passt
• Die Firmware meldet, dass die Applikation nicht passt

Gruß, Waldemar

[thewhobox]

mumpf Genau. Post 1002 zeigt, wie man es in der ETS unterbindet.

<LdCtrlRelSegment LsmIdx="4" Size="256" Mode="0" Fill="0" />

Den Befehl kennst ja schon. Das allociert den Speicher für die Applikation (LsmIdx=4). (Mode=0 heißt kein überschreiben des Speichers mit Fill)

<LdCtrlCompareProp InlineData="00FA020723" ObjIdx="4" PropId="13">
<OnError Cause="CompareMismatch" MessageRef="M-00FA_A-0207-23-E298_M-1" />
</LdCtrlCompareProp>

Hier kommt nun die Überprüfung. Es wird die Property 4-13 abgefragt und mit den Bytes von InlineData verglichen.
Sind diese unterschiedlich schlägt es fehl und der Fehler wird geworfen.
Die Property kann allerdings überschrieben werden. Es muss also von Anfang an die richtige Applikation drauf sein (oder der Stack gibt hier feste Parameter zurück, dafür kenne ich den Stack zu wenig)

Im vorigen Verlinken KNX-Support eintrag (der nun ein 404 ist -.-) wurde beschrieben, dass der PID_Hardware-Type (Property 0-78) dafür besser geeignet ist, da hier die Hardware verglichen wird. Somit können auch Updates übertragen werden (im obigen Beispiel geht nur Version 23 -> V1.7)
Verfügbar sind 6 Bytes. Warum in Inline mehr drin steht weiß ich nicht.
Wie man den Hardware Type im Stack festlegt weiß ich nicht, die Ladeprozedur müsste dann aber so aussehen:

<LdCtrlCompareProp ObjIdx="0" PropId="78" InlineData="00000000022600000000" />
<OnError Cause="CompareMismatch" MessageRef="M-00FA_A-0207-23-E298_M-1" />
</LdCtrlCompareProp>

(Hier geklaut aus einem MDT Gerät)
MDT scheint den Hardware Type einfach pro Hardware um 1 zu erhöhen.

<Messages>
 <Message Id="M-00FA_A-0207-23-E298_M-1" Name="EM_APmismatch" Text="This application program can only be used for device D7." />
</Messages>

Die Nachricht erklärt sich glaub von selbst^^

[thewhobox]

So nun mal theoretisch überlegt wie man das im Stack erkennen kann.

Mir würde folgendes einfallen:
Ein Parameter (Name=ApplikationTest, Type=None,Value=0xD3D3, Speicher=Memory0x00, Access=None)
Der Parameter wir dann in der dynamischen Ansicht eingefügt, aber er wird nicht angezeigt, da Zugriff auf keiner ist.

Beim starten der Applikation würde ich nun den Parameterwert im Speicher abfragen.
Wenn er den Wert 0xD3D3 hat: weiter machen.
Falls nicht wurde ne andere Applikation übertragen.

Da vor dem Übertragen auch der Hersteller abgefragt wird, hält sich die Anzahl an Applikationen die Übertragen werden können in Grenzen (KNX Virtual und DIY Geräte)
Die Wahrscheinlichkeit hier eine Überschneidung zu haben ist relativ gering, aber immer noch da.

Zweiter Gedanke: Eine eigene Property beschreiben.
Auf anhieb würde mir die PID_Description einfallen.
In der Ladeprozedur einfügen:

<LdCtrlWriteProp ObjIdx="0" PropId="21" InlineData="00123456" />

Mit dem Stack müsste man dann den Wert der Property auslesen und natürlich auch iwie beim Unload des Speichers auch die Property zurücksetzen.

[mumpf]

Hi, erstmal danke für die ausführliche Antwort.

Zum ersten Teil komme ich noch, der 2. Teil ist mir relativ klar.

Mir würde folgendes einfallen:
Ein Parameter (Name=ApplikationTest, Type=None,Value=0xD3D3, Speicher=Memory0x00, Access=None)
Der Parameter wir dann in der dynamischen Ansicht eingefügt, aber er wird nicht angezeigt, da Zugriff auf keiner ist.

Falls das jemand machen will, habe ich ein Pattern erarbeitet, das auch stabil gegenüber Applikations-Updates in der ETS bleibt. Sonst hat man bei einem Update keine Chance, den Wert (bei Value) zu ändern.

<ParameterType Id="M-00FA_A-0001-01-0000_PT-AppID" Name="AppID">
    <TypeNumber SizeInBit="32" Type="unsignedInt" minInclusive="12345678" maxInclusive="12345678" />
</ParameterType>
...
<Parameter Id="M-00FA_A-0001-01-0000_P-1" Name="AppID" ParameterType="M-00FA_A-0001-01-0000_PT-AppID" Text="AppID" Value="12345678" Access="None">
    <Memory CodeSegment="M-00FA_A-0001-01-0000_RS-04-00000" Offset="0" BitOffset="0" />
</Parameter>

Wenn man das so macht, enthält der Parameter IMMER die AppID, auch nach einem Update. Der Typ mit minInclusive = maxInclusive wirkt quasi wie eine Konstante. Ansonsten wird bei einem Update der alte Wert immer beibehalten und nicht aktualisiert.

So, das habe ich verstanden, jetzt zum ETS-Teil, der nicht in meinen Kopf will - aber in der nächsten Antwort.

[mumpf]

Hi Mike,

eigentlich birgt dieser Satz das Problem, dass ich nicht verstehe:

Hier kommt nun die Überprüfung. Es wird die Property 4-13 abgefragt und mit den Bytes von InlineData verglichen.

Der Punkt ist doch der, dass ich Properties (zumindest soweit ich das verstehe) mit

<LdCtrlWriteProp ObjIdx="4" PropId="13" InlineData="12345678" />

aus der Applikation schreiben muss. Dann ist die Überprüfung trivial, denn ich bekomme natürlich den selben Wert zurück. Und wenn ich das Property nicht schreibe, woher soll dann der Wert kommen, wenn nicht vom Stack?

Da hänge ich dran und weiß nicht, wie man da rauskommt.

Gruß, Waldemar

[thewhobox]

Dann ist die Überprüfung trivial, denn ich bekomme natürlich den selben Wert zurück.

Wenn du nur eine Gerät im Kopf hast, ja dann ist es trivial.

Jetzt nehmen wir mal an du hast dein Sensormodul, das EnocianGateway und das Modbus Gateway.
Ohne die Property zu vergleichen könntest du das mischen wie du lustig bist, da Hersteller und Maskenversion bei allen gleich sind.
Evtl bricht es ab, wenn die Speicher unterschiedlich groß sind und man in einen geschützten Bereich schreiben möchte. Aber in dem Fall ist die Fehlermeldung "Es wurde versucht in einen geschützen Bereich zu schreiben" wenig hilfreich.

Die Property Hersteller 0-12, OrderInfo 0-15 oder SerialNumber 0-11 musst du ja auch nicht in der Ladeprozedur vorher schreiben. Die sind im Stack festgelegt.

Wenn du nun jedem einen eigenen Wert in der Property gibst (Enocian=0xD1, Modbus=0xD2, Sensormodul=0xD3) dann kannst du das in der Ladeprozedur abfragen. Und hier ist es ja gut, dass der Stack dann den festeinprogrammierten Wert hat, da die Firmware nur für den Typ 0xD2 gültig ist.

[mumpf]

Ok,

ich muss nochmal etwas durch den Stack debuggen und mir ein Bild von den Properties zu machen. Aber ich verstehe es jetzt zumindest wo weit, dass ich irgendwo im Coding in meiner Firmware dann das Property 4-13 setzen müsste (oder irgendein anderes) und dann könnte ich das in der Ladeprozedur überprüfen. Ich hab mich von Deiner Aussage

Das ist nicht die Aufgabe des Stacks.
Solche Sachen gehören in die Ladeprozedur in der Apllikation.

verwirren lassen. Ich dachte irgendwie, dass man gar nichts dafür machen muss. Jetzt verstehe ich das besser, vielen Dank.

Gruß, Waldemar