Ich glaube bei Konnekting gibt es auch noch eine FlashAsEeprom-Variante. Vielleicht ist die besser?
Ankündigung
Einklappen
Keine Ankündigung bisher.
ESP8266 KNX mit ETS
Einklappen
X
-
Zitat von thesing Beitrag anzeigenFür ein Update der knxprod eines Gerätes muss du übrigens wie folgt vorgehen.
Gruß, Waldemar
Kommentar
-
Ok, habe jetzt gesehen, dass bei mir im XML das Attribut ReplacesVersions fehlte. Da ich ja das XML manuell editiere und CreateKnxProd nur zum umwandeln in knxprod nutze, hatte ich nicht die neueste Version hier und konnte nicht die passenden Sachen "abgucken". In der Doku steht, dass da eine Liste von alten Versionen stehen kann (und der Name lässt das auch vermuten), allerdings ist es nur ein String. Weißt Du, wie die Liste notiert wird? Durch Leerzeichen getrennt? Durch Komma? Wahrscheinlich werde ich sowieso nur von der vorherigen auf die nächste müssen, aber mich würde das Format interessieren.
Ich werde mal mein XML an die ganzen Neuerungen anpassen, die ich in dem Output vom aktuellen CreateKnxProd gesehen habe und dann weiter testen...
Danke und Gruß,
Waldemar
Kommentar
-
-
mumpf in der Hilfedatei vom MT (muss man das MT für installieren) steht noch genaueres zum Update:
KNX Manufacturer Tool Update Application Program KNX Manufacturer Tool, Latest Update: 11/17/2017, © 2017 KNX AssociationThis function is called "Update Application Program" in the ETS4 / ETS5 UI.
The functionality is not available in ETS3.
When is the function available?
The function is available if a device is selected and there is an Application Program in the Database (ETS4) or Product Store (ETS5) which has:
·the same Manufacturer and ApplicationNumber as the currently assigned application program
·a higher version number
·contains the existing version in its "Replaces Versions" attribute (see ApplicationProgram).
·is linked to the same hardware
Note: If the new application program is not registered, a special "Replace unregistered products" license has to be installed in ETS.
How does the function work?
The function first creates a new device in the project with the newer application program.
Then the parameter values are transferred: For each ParameterRef of the old application program, a corresponding ParameterRef of the new application is determined by matching UniqueNumber. If no match has been found, the parameter is ignored (without error). Otherwise ETS tries to assign the existing parameter value to the device parameter corresponding to the new ParameterRef. This might fail if parameter types have been changed; such a failure is logged to the ETS log file but is otherwise ignored (the new parameter keeps its default value).
Then the communication objects are transferred: For each ComObjectRef of the old application program, a corresponding ComObjectRef of the new application is determined by matching object number and size. If no match has been found, the object is ignored (with a warning logged if the old object had associations). Otherwise ETS assigns the existing object flags and associations to the device object corresponding to the new ComObjectRef. If the old device object had a datapoint type assigned, but the new has not, the datapoint type is also transferred.
What does this imply for the application program?
The algorithm described above works only as expected if the following restrictions regarding the relation between the new and the old application program hold. It is the manufacturer's responsibility to ensure these restrictions.
·The UniqueNumber of ParameterRefs must be unique within the application program (the MT enforces this only for ParameterRefs assigned to the same Parameter/UnionParameter)
·The UniqueNumber of ParameterRefs that are present in both the new and the old application program must be identical
·If a ParameterRef of the old application program has no correspondence in the new application program, its UniqueNumber must not be re-used.
·Care must be taken if the ParameterType of a Parameter has changed. This may make taking over of parameter values impossible.
·Adding new ParameterRefs is no problem, they will keep their default values
·The object Number of ComObjectRefs that are present in both the new and the old application program must be identical
·If a ComObjectRef of the old application program has no correspondence in the new application program, no other ComObject of the same size must be at this Number in the new application program.
·Adding new ComObjectRefs is no problem, the will keep their default settings
Zuletzt geändert von thesing; 15.07.2019, 22:19.
Kommentar
-
Hi,
ich habe gerade (mal wieder) mein Projekt "zerbastelt", aber sobald das wieder kompilierbar ist, werde ich gerne den DPT9 mit vielen Werten durchtesten. Dauert aber noch 1-2 Tage. Werde berichten...
Gruß, Waldemar
Kommentar
-
Zitat von thesing Beitrag anzeigenSo ich glaube dass Dpt9 nun nach einem einfachem if(value > 2048) wieder wie vorgesehen funktioniert.
Mag Gyver Danke trotzdem für deine Mühe. Ich lass den Pull-request noch offen falls doch noch was falsch ist.
Bei mir liefert der BME-Sketch immer noch „0- Werte“ in der aktuellen Version aus github.
Grüße Johannes
Zuletzt geändert von jorues; 16.07.2019, 21:38.
Kommentar
-
Hi Thomas,
danke für die Doku, das ist prima - und zeigt mir gleich, dass meine manuell editierten ParameterRef-IDs neu gemacht werden müssen, ich verletze eindeutig diese Forderung:
Zitat von thesing Beitrag anzeigen·The UniqueNumber of ParameterRefs must be unique within the application program
Gruß, Waldemar
Kommentar
-
Zitat von jorues Beitrag anzeigen
Bei mir bringt liefert der BME-Sketch immer noch „0- Werte in der aktuelle Version von gihub. Grüße Johannes
Kommentar
-
Hallo Thomas,
kein Problem. Dafür ist ein Pullrequest ja schließlich da. Ab und zu soll Er einfach nur eine Anregung darstellen oder gleich komplett das Problem lösen.
Leider konnte ich deine Änderungen dazu noch nicht testen.
Hast du mal über einen Test-Sketch nachgedacht? Damit der nicht so ambitionierte User eine Referenz (Beispiel hat, wie er bestimmte Sachen benutzen kann) …
Grüße
Mag Gyver
Kommentar
-
HI,
habe soeben mal mit der aktuellsten Version den Linux-Part getestet. DPT9 funktioniert korrekt (zumindest unter Linux), habe es mit zufälligen Werten zwischen -1000 und 1000 versucht, und alle waren korrekt (also der Wert, den die ETS gesendet hat, wurde von meinem Modul auch als DPT9 exakt wieder so gesendet.
Als nächstes steht immer noch SAMD an, da war ich bisher nicht erfolgreich.
Danke und Gruß, Waldemar
Kommentar
-
Hi,
wollte mal wieder einen - diesmal frustrierten - Zwischenbericht geben...
Versuche gerade, das Ganze auf den SAMD zu bringen, dabei verwende ich den gleichen, den Thomas nutzt (https://www.ebay.de/itm/WeMos-D1-SAM...frcectupt=true). Folgendes Vorgehen:- Ich nutze die Adruino IDE mit dem passenden SAMD Cortex M0 board
- Mit dem Standard Blink-Beispiel habe ich die Onboard-LED über GPIO 26 zum blinken gebracht
- Mit dem Standard Button-Beispiel habe ich die Programmiertaste am GPIO 10 ausprobiert (Tastendruck bringt LED zum leuchten)
- Sobald ich aber die knx-demo aus der Lib hier verwende (die beiden GPIO 26 und 10 sind entsprechend angepasst), funktioniert nichts mehr: Der Prog-Button lässt die LED nicht leuchten, das Gerät ist nicht über den Bus zu erreichen (RX/TX sind auf GPIO 0/1)
- Das blödeste: Der SAMD ist dann auch nicht mehr über USB zu erreichen, ich kann also nichts weiter machen und den z.B. neu flashen.
Ich habe zwar noch einen 3. neuen SAMD hier, aber wollte den nicht opfern, bevor ich weiß, was da los ist... Habe aber leider auch noch nicht so viel mit Arduino gemacht, dass ich genauere Details nachschauen und so sinnvolle Details liefern könnte.
Bin über jeden Tipp dankbar, Waldemar
P.S.: Noch was positives hinterher - ich habe unter Linux endlich die Flags getestet, sie verhalten sich jetzt richtig. Ebenso habe ich inzwischen getestet, wie der KNX-Stack auf selbst gesendete Telegramme reagiert - das tut er IMHO korrekt.Zuletzt geändert von mumpf; 21.07.2019, 12:36.
Kommentar
Kommentar