ESP8266 KNX mit ETS

[jeff25]

Hi,

man eine evtl dumme Frage, kann ich ein knx.getGroupObject auch aktualisieren ohne auf den Bus zu schreiben?
Bzw ich würde gerne nur per Lesebefehl ein Gruppenobjekt auslesen und das periodisch auf den Bus schreiben deaktivieren...
(Linux_Demo Beispiel)

Viele Grüße
Robert

[mumpf]

Vielleicht reicht auch einfach ein xml-Editor mit xsd-Validierung und Autocomplete?

Ja, das glaube ich auf jeden Fall, würde ich auch gerne nutzen, aber hast Du eine Idee, wo das Schema für das von Dir mit CreateKnxProd erzeugte xml zu finden ist?

Ansonsten - wenn man etwas intensiver mit den XML-Files arbeiten will - reicht nicht nur ein Programm zum signieren. Man braucht Rechneruntersützung für die folgenden Punkte (zumindest haben mir diese Checks die Arbeit wesentlich erleichtert):

• Id-Neuberechnung für alle Objekte basierend auf ApplicationNumber und ApplicationVersion
• Automatische Durchnummerierung von Channel-, ParameterBlock- und ParameterSeparator-Elementen (und weiteren, nicht referenzierten Elementen)
• Berechnung der Größe aller Parameter (und automatische Eintragung in die passenden Size-Attribute)
• Erzeugen von Registrierungseintrag aus HardwareVersion und ApplicationVersion
• Anpassen des xmlns an ETS4, ETS5 oder ETS5.7
• Erzeugen eines Headerfiles mit allen Parametern und deren Offsets
• SanityCheck: Alle Id sind eindeutig
• SanityCheck: Alle verwendeten RefId sind auch als Id definiert
• SanityCheck: Alle verwendeten ParamRefId sind auch als Id definiert
• SanityCheck: Alle verwendeten ParameterType sind auch als Id definiert

Ich stimme Dir zu, Thomas, dass das nicht sehr viel Coding ist, aber ich bin auch schon bei 500 Zeilen und wenn ich das schön mache, dann werden es eher 1000-2000.

ABER: Ich finde CreateKnxProd mit seinem simplen UI echt klasse für den Einstieg! Deswegen würde ich das ungern missen wollen... Der occasional User, der einfach mal einen Sensor am SAMD auswerten will und etwas rumspielen will, findet so auf einfache Weise einen Einstieg.

Gruß, Waldemar

[thesing]

Vielleicht reicht auch einfach ein xml-Editor mit xsd-Validierung und Autocomplete? Und die entstehende xml-Datei dann normal signieren.

[mumpf]

Hi Fabian,

ich habe den hier genommen: https://www.nuget.org/packages/Syste...eview9.19421.4, aber es gibt inzwischen ein rc1, kannst auch den probieren. Vor allem, falls Du vom netcore auch den rc1 installiert hast, solltest Du auch vom ConfigurationManager den rc1 nehmen. Irgendwie hängen die zusammen...

Gruß, Waldemar

[metaneutrons]

@mumpf: Ich habe inzwischen auch auf net.core 3.0 beta umgestellt. Jetzt ärgert mich noch der ConfigurationManager, obwohl ich den natürlich referenziert habe:

Error: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

 ---> System.TypeInitializationException: The type initializer for 'Knx.Ets.Converter.ConverterEngine.ConvertBase' threw an exception.

 ---> System.TypeInitializationException: The type initializer for 'log4net.Core.LoggerManager' threw an exception.

 ---> System.TypeInitializationException: The type initializer for 'log4net.Util.SystemInfo' threw an exception.

 ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

File name: 'System.Configuration.ConfigurationManager, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

   at log4net.Util.SystemInfo.GetAppSetting(String key)

   at log4net.Util.SystemInfo..cctor()

   --- End of inner exception stack trace ---

   at log4net.Util.SystemInfo.AssemblyLocationInfo(Assembly myAssembly)

   at log4net.Core.LoggerManager.GetVersionInfo()

   at log4net.Core.LoggerManager..cctor()

   --- End of inner exception stack trace ---

   at log4net.Core.LoggerManager.GetLogger(Assembly repositoryAssembly, String name)

   at log4net.LogManager.GetLogger(Assembly repositoryAssembly, String name)

   at log4net.LogManager.GetLogger(Type type)

   at Knx.Ets.Converter.ConverterEngine.ConvertBase..cctor()

   --- End of inner exception stack trace ---

   at Knx.Ets.Converter.ConverterEngine.ConvertBase.Uninitialize()

   --- End of inner exception stack trace ---

@thesing: Hmm, eine wirklich vollständige GUI (á la KNX MT) zu entwickeln dürfte sehr viel Aufwand sein. Ich will den Fokus ebenfalls möglichst schnell (wieder) auf die Geräteseite bekommen. Avalonia werde ich mir mal nähere anschauen. Ich würde tatsächlich liebe ein flexibles Tool auf der Kommandozeile nutzen als ein GUI-Tool, weil es besser zu meinem Workflow passt. Ob und wie gut das gelingt, muss ich mir aber nochmal in Ruhe anschauen und überlegen.

@mumpf: Über Deinen Ansatz mit einem Präprozessor habe ich auch schon nachgedacht. Das wäre wahrscheinlich flexibler als ein GUI-Tool und vermutlich auch einfacher zu implementieren. Könnte ich mir (jedenfalls in der Theorie) gut vorstellen.

Ich versuche jetzt erstmal die letzten Fehler zu beseitigen. Vielleicht editiere ich einfach auch nur die XML-Dateien und nutze das Tool lediglich zum signieren.

Herzliche Grüße einstweilen,
Fabian

[thesing]

Ohne GUI ist die Funktion doch eigentlich nur: Ids erzeugen und Datei signieren. Das ist so wenig Code, es sich nicht lohnt das aufzuspalten. Eine Kommandozeile würde ich nicht zum vollständigen Erstellen nutzen wollen. Das avaloniaui sollte man relativ leicht einbauen können. Ich habe damit aber noch nicht gearbeitet.

Prinzipiell ist mein Fokus aber auch eher auf der Geräteseite. Die GUI ist nur ein notwendiges Übel.

VG
Thomas

[mumpf]

Hi,

was ist denn der Fehler? Ich bin auch über einige Fallen gestolpert und hab sie alle lösen können - die letzte dann allerdings nur, indem ich auf core3.0-beta gegangen bin.

thesing: Ich habe leider auch keine Erfahrungen mit GUI unter netcore, aber man könnte das ja mit der Idee von Fabian verbinden: Es gibt eine Library, die das Management der xml-Files übernimmt und verschiedene Frontends: ein Kommandozeilen-Tool und ein GUI-Tool. Ich könnte mal schauen, was von meinem Kommandozeilen-Tool auszugliedern wäre, um das bei Fabian mit aufzunehmen, ich habe inzwischen einige "Sanity-Checks" gemacht.

Ich wäre z.B. viel mehr dran interessiert, die resultierenden XML-Files, die als input für den ETS-Converter dienen, über einen Präprozessor zu erzeugen, der á la XInclude wiederverwendbare Teile nutzen kann (ParameterTypes sind dafür ein Kandidat, aber auch ganze paramter-Bereichte). Und dann an einer Template-Engine, die sich wiederholende XML-Blöcke generiert. Und dann noch an einem Headerfile-Generator...

An sich habe ich die obigen Teile schon, aber eher "verwoben" in einem Tool, dass wohl kein anderer auf der Welt nutzen könnte .

Ein GUI-Tool werde ich wohl nicht benutzen und bin deswegen eher weniger daran interessiert, sorry.

Gruß, Waldemar

[metaneutrons]

Moin zusammen!

Danke mumpf für den Hinweis mit dem Encoding. Läuft jetzt bei mir. Leider ist im NetCore die Cryptographie offenbar noch nicht vollständig implementiert. Da gibt es derzeit den nächsten Fehler. Ich schaue mir das die Tage an.

@thesing: Ja, da stimme ich Dir zu. Ich habe mir bereits https://avaloniaui.net angeschaut. Hast Du Erfahrungen mit einem Cross-Plattform GUI Toolkit unter C#? Ich habe leider überhaupt keine Erfahrungen mit GUI-Apps unter C# - egal welches GUI Framework. Die Funktionalität für das Bearbeiten der XML-Dateien in eine Bibliothek zu verlagern schien mir aber ein sinnvoller Zwischenschritt zu sein. Würdest Du eine Weiterarbeit an CreateKnxProd als Monolith bevorzugen?

Herzliche Grüße, Fabian

[thesing]

Ich würde es besser finden, einfach eine platformübergreifendes GUI-Toolkit zu nutzen, und das gleiche Programm ggf. per Kommandozeile aufrufbar zu machen.

VG
Thomas

[mumpf]

Hi Fabian,

über das Problem bin ich auch schon gestolpert, ist einfach zu lösen... ich habe folgendes Statement gefunden gehabt:

It turns out that some “exotic” encodings (including popular Windows-1252) are defined in separate NuGet package and these encodings are not available by default.

Solution is simple. Add System.Text.Encoding.CodePages NuGet package to solution and use the following piece of code in application startup class to registester new encodings.

    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

Dann geht das auch wieder...

Gruß, Waldemar

[metaneutrons]

Moin zusammen,

auf die Gefahr, das es hier nicht so gut hinpasst (dann bitte Hinweis, ob ich einen neuen Thread aufmachen soll): Ich habe das CreateKnxProd von thesing versucht in eine Bibliothek zu migrieren. Hintergrund ist, dass ich auf dem Mac entwickele und eine WPF-Applikation dort nicht läuft und ich ohnehin lieber eine Kommandozeilenversion nutzen möchte. Ihr findet das Ergebnis meiner Bemühungen unter https://github.com/metaneutrons/KnxProd. Die Bibliothek nutze ich selber für mein Kommandozeilen-Tool mknx, welches unter https://github.com/metaneutrons/mknx verfügbar ist.

Wer Lust hat das zu testen, klont am besten beide Repos und erzeugt eine übergeordnete Solution in die man dann beide Projekte lädt.

Ich muss einräumen, dass ich aller andere als ein C#-Experte bin; das Erstellen/Bearbeiten der XML-Dateien funktioniert bei mir jedoch tadellos.

Ein Problem gibt es aktuell noch beim Erstellen der knxprod-Datei. Dort erhalten ich aus dem Invoke der Knx.Ets.Converter-Dlls folgenden Fehler:

System.TypeInitializationException: The type initializer for 'Knx.Ets.Converter.ConverterEngine.ConvertBase' threw an exception. ---> System.NotSupportedException: No data is available for encoding 1252. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method.

   at System.Text.Encoding.GetEncoding(Int32 codepage)

   at Knx.Ets.Converter.ConverterEngine.ConvertBase..cctor()

Lade ich die vom meinem Tool erzeugte XML-Datei in CreateKnxProd und exportiere dort, tritt der Fehler nicht auf. Das Problem scheint auch nicht mit dem Mac zu tun zu haben, da er auch unter Windows auftritt.

Pull-Requests sind jederzeit hochwillkommen!

Herzliche Grüße, Fabian

[henfri]

Hallo nochmal,

davon abgesehen funktioniert der Sketch jetzt aber wie erwartet!!
Danke!
Es war allerdings nötig "Erase Flash, All Content" zu wählen. Vorher ging es nicht.

Gruß,
Hendrik

[henfri]

Hallo,

ich versuche gerade den bme680 wieder zu beleben.
Du benutzt ja die 1.4.7.3. Bisher benutzte ich die 1.4.7.1.
Die .3 gibt es nicht mehr zum Download. Also habe ich auf die .4 Aktualisiert. Das lief nicht mit meiner älteren Arduino IDE.
Also die auch neu installiert. Nochmal durch die Installations-Hölle der BSEC-Lib. Beispiel-Sketch der BSEC-Lib kompiliert.

Aber dein BSEC-Sketch nicht. Da haben die also wieder an der Syntax gefummelt. Das ist echt unschön (nicht von dir, von denen). Ich frage mich was das soll. Die könnten die API doch echt mal stabil halten, zumindest wenn sich die vierte Nachkommastelle ändert...

H:\HeimNetzwerk\espknx\BME680\knx-bme680\knx-bme680.ino: In function 'void loop()':

knx-bme680:139:43: error: 'class Bsec' has no member named 'iaq'

         output += ", " + String(iaqSensor.iaq);

Ich denke, das muss jetzt iaqEstimate heißen (ich glaube, das war in einer früheren Version tatsächlich auch schon einmal so)

Gruß,
Hendrik

[mumpf]

Danke für die Rückmeldung, dann passe ich mal mein Coding entsprechend an und teste mal weiter mit restart...

Zum negativen confirm: Soweit ich die Spec noch in Erinnerung habe (Ich habe nicht alles gelesen, von dem Gelesenen nicht alles verstanden und von dem Verstandenen wahrscheinlich einiges falsch verstanden ), wird ein Connect nicht bestätigt bzw. man muss auf keine Bestätigung warten, deswegen gibt es auch kein "negatives confirm". Deswegen liest die ETS (und inzwischen hab ich das auch bei anderen Geräten, die ein connect machen, beobachtet) gleich den DeviceDescriptior hinterher. Wenn da ne Antwort kommt, weiß man, dass der Connect geklappt hat. Du hast auch den Connect so implementiert, ich hab mich mal durch die StateEngine durchdebugged und nach A12 wird mehr oder weniger gleich auch die A13 und somit immer ein positiver connectConfirm aufgerufen.

Ich wolle damit nur sagen, dass man gar nicht auf   if (status)  abfragen müsste, das Ding wird wohl nie mit "false" aufgerufen...

Gruß, Waldemar

[thesing]

mumpf Das ist schon richtig so. Der tsap ist in dem Fall nicht die Zieladresse, sondert die Verbindungsnummer, die vorher aufgebaut wurde. Da das aktuelle Transportlayer nur eine Verbindung auf einmal kann, ist der tsap 0, wenn es eine Verbindung gibt, und -1 sonst.
Theoretisch könnte auch ein negatives confirm kommen, wenn es beim Senden einen Fehler gibt. Ggf. fehlt das.

VG Thomas