ESP8266 KNX mit ETS

[mumpf]

Dann sollten wir uns aber auf irgendein ID-Schema einigen

Du hast natürlich Recht, ich sehe aber das Problem eher bei der Applikationsnummern. Ich hab z.B. bei meinem Experimenten schon 100-110, 120, 130, 140, 150, 160 und 170 genutzt. Ist alles nicht freigegeben (außer das Sensormodul mit 106). 2 weitere hab ich in Petto, da kann ich die nummern noch anpassen. Ich wollte - solange es geht - im Bereich 100-110 bleiben.

Mein einfacher Vorschlag: Die AppID, die man vergibt, ist im ersten Byte = Applikationsnummer. Schon haben wir keine Kollisionen im Bereich der ID .

Gruß, Waldemar

[Ing-Dom]

mach das doch so wie von mir im Post 1062 beschrieben.

probier ich auch mal aus.

Dann sollten wir uns aber auf irgendein ID-Schema einigen sonst haben wir alle 12345678 drin stehen

[mumpf]

Hi,


mach das doch so wie von mir im Post 1062 beschrieben. Typ definieren, Parameter mit dem Typ, ParameterRefRef im Dynamic-Teil und im Coding abfragen. Einfacher geht es nicht.

Gruß, Waldemar

[philipp900]

Das ist jetzt alles ziemlich theoretisch hier.

Ich suche nach einer einfachen Lösung in meiner programmierten Applikation (ESP Firmware) zu überprüfen ob das für diesen Anwendungsfall erstellte knxprod auch wirklich in das Gerät geladen wurde. Eine Überwachung in der ETS ist gar nicht nötig.
Abfangen will ich einfach nur diesen Fall:
Wenn die Firmware auf nicht konfigurierte Groupobjects zugreifen will (weil passende Applikation mit ETS noch nicht geladen), kommt es zu einem Zugriffsfehler im Stack und der Chip startet neu.

"<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.

Genau so einen Wert würde ich gerne in der Firmware abfragen.
Soweit ich gesehen habe bietet die aktuelle Implementierung aber keine Funktion dafür.

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.

Auch das ist mit der aktuellen Implementierung und dem CreateKnxProd nicht möglich.

[thewhobox]

Ja das war vll etwas blöd ausgedrückt. Ich meinte, dass der Stack nichts aktives macht um das zu verhindern.
Aber ja, das ist korrekt. Iwo musst du die Property mit dem Stack setzen, damit du sie per ETS auslesen kannst.

Gerne doch

Gruß Mike

[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

[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]

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

[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.

[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.

[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^^

[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]

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)

[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]

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