Ankündigung

Einklappen
Keine Ankündigung bisher.

ESP8266 KNX mit ETS

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Dem Stack ist das egal. ETS fragt beim programmieren die Mask-Version vom Gerät ab und vergleicht die.

    Kommentar


      Hi Thomas,

      Zitat von thesing Beitrag anzeigen
      Mask-Version
      ich habe heute den ganzen Tag Informationen zur Mask-Version gelesen, bin aber nicht viel schlauer. Verstehe ich das richtig, dass das jetzt noch die Abhängigkeit ist, die verhindert, dass ich eine knxprod für IP und TP haben kann? Denn in der knxprod muss ich ja unter Application eine MaskVersion angeben. Und da das Attribut nicht MaskVersions heißt, wird da wohl auch nur eine angegeben werden können. Und nach der Info, die ich gefunden habe, gibt die erste Stelle der MaskVersion die Kommunikation vor: 0=TP, 5=IP. Ich kann das im Urlaub nicht ausprobieren, aber ich würde jetzt erwarten, dass die ETS meckert, wenn ich meine knxprod von der TP-Linie auf die IP-Linie schiebe und das entsprechende (linux) Gerät dort versuche zu programmieren... Mist.

      Könnte der Linux-Stack die MaskVersion 07B0 (statt 57B0) zurück geben und trotzdem noch korrekt funktionieren? Vielleicht nur in einer lokalen Modifikation bei mir (verletzt ja sicher die Spec)? Wie gesagt, mir sind da die Abhängigkeiten nicht wirklich klar...

      Aber was solls, das ist ein Problem, dass ich sowieso erst nach meinem Urlaub weiter untersuchen kann, ich versuche erstmal weiter, meine knxprod zu versionieren und upgradebar zu machen, irgendwas mach ich da noch falsch...

      Gruß, Waldemar

      Kommentar


        So,

        nach einer Nacht-Session habe ich jetzt eine versionierbare knxprod (Fehler war trivial, aber das weiß man immer erst, nachdem man ihn gefunden hat ). Nachdem mir eingefallen ist, wie ich auch remote den Linux-Stack testen kann, habe ich es gleich versucht:
        1. Wie erwartet hat die ETS gleich gemeldet, dass die Mask Version 57B0 ist, aber 07B0 erwartet wird.
        2. Nachdem ich die Mask Version in bau57B0.h auf 07B0 geändert habe, konnte ich auch den Linux-Stack per IP mit meiner knxprod programmieren.
        Ich bin jetzt glücklich damit, aber ich weiß nicht, ob ich durch die "falsche" Mask Version in bau57B0.h nicht irgendwelche Seiteneffekte auslöse. Kann dazu irgendjemand was sagen?

        Ansonsten hätten wir jetzt einen Stack, der mit einer knxprod TP und IP unterstützt. Das finde ich ziemlich komfortabel...

        Gruß, Waldemar

        Kommentar


          Hi,

          ich habe mir nochmal DPT9 angesehen. Mit dem ist alles OK , allerdings nicht, wenn man intern mit float arbeitet. Mit double klappt alles. Da die knxdemo auch mit float arbeitet, wird da auch immer 0 gesendet.

          Für eine Korrektur muss man in knx_value.cpp:
          Code:
          KNXValue::KNXValue(float value)
          {
             _value.doubleValue = value;
              _type = DoubleType;
          }
          einfach das rote hinzufügen.

          Edit: Habe jetzt einen Pull-Request gemacht (https://github.com/thelsing/knx/pull/27)

          Gruß, Waldemar
          Zuletzt geändert von mumpf; 16.08.2019, 17:16. Grund: Pull-Request zugefügt

          Kommentar


            Danke für die Mühe.

            Ich glaube nicht, dass ich die zwei Zeilen vergessen habe... Kannst du bei der Änderung an der KnxFacade mal schauen warum die ganze Datei im Pull-Request als geändert angezeigt wird? So kann ich schwer sehen, was wirklich anders ist. Bin gerade im Urlaub. Sonst würde ich selber schauen.

            Kommentar


              Hi Thomas,

              danke für die Antwort - trotz Urlaub. Sorry, das war mein erster Pull-Request, und schon ging es schief. Ich habe eigentlich nur die Änderung für DPT9 in den Pull-Request gepackt, der 2. change danach sollte noch nicht rein, weil ich auch gesehen habe, dass da alle Zeilen im diff sind. Ich habe aber noch nicht rausfinden können, warum, der erste Verdacht LF statt CRLF oder umgekehrt ist es wohl nicht. Eigentlich wollte ich den change zurücknehmen, aber wie gesagt, ich dachte, das wäre alles lokal bei mir...

              Ich bin auch im Urlaub , werde aber morgen gleich schauen. Ich hab eigentlich auch noch DPT16 fertig gemacht, will das aber nicht pushen, solange ich das mit den full file changes nicht im Griff habe...

              Genieße erstmal Deinen Urlaub, das mit dem Pull ist nicht eilig.

              Gruß, Waldemar


              Kommentar


                Hi Thomas,

                ich hab das mal untersucht, ich habe 3 Linux Maschinen, auf 2 davon geht git clone ohne probleme, auf meinem Entwicklungsrechner sind aber direkt nach dem clone gleich 18 files "modified", und es sind doch die mit CRLF. Es liegt an .gitattributes, da der Eintrag text = auto. Wenn ich den auskommentiere, dann klappt es. Warum das nur auf dem einen Linux-Rechner so ist und nicht auf den anderen beiden, weiß ich nicht. Der einzige weitere Unterschied ist, dass die beiden funktionierenden unter Debian, der Entwicklungsrechner auf Ubuntu läuft.

                Hat hier sonst noch jemand solche Probleme? Und wie habt ihr sie gelöst?

                Ich werde jetzt nochmal versuchen, eine bereinigte Version zu pushen, damit der Pull-Request besser aussieht.

                Gruß, Waldemar

                Kommentar


                  Hi Thomas,

                  ich nochmal... ich habe jetzt zwar eine Datei mit den korrekten CRLF hochgeladen, aber da github immer den diff zum letzten commit anzeigt, wird dieses File natürlich auch vollständig als diff angezeigt. Ich habe aber folgende Möglichkeit im github entdeckt:
                  hideWhitespaces.PNG
                  Damit kannst Du die Changes meines ersten commit sehen und auch sehen, dass der 2. commit keine programmrelevanten Änderungen enthält. Ich werde in Zukunft genauer drauf achten. Für mich ist es auch neu, dass alle meine commits automatisch zu einem pull request werden? Das hätte ich nicht erwartet...

                  Gruß, Waldemar

                  Kommentar


                    Hi Thomas,

                    ich habe noch einen Pull-Request für DPT16 nachgeschoben, bisher wurde das nur vom Bus gelesen, konnte aber nicht geschrieben werden (https://github.com/thelsing/knx/pull/28/files). Ich habe das Gefühl, dass ich da was falsch mache, denn es sind 5 commits in dem pull request, obwohl ich vorher mein Repository auf den selben Stand wie Dein Repo gemerged habe. Es ist aber nur 1 File unterschiedlich, das ist soweit korrekt.

                    Bin für Hinweise dankbar, was man hier besser machen kann, denn ich wollte nochmal (nach Absprache mit Dir) noch eine größere Änderung rein bringen, die den "Restart device" Befehl realisiert - den habe ich jetzt mal erfolgreich realisieren können, allerdings noch experimentell.

                    Aus meiner Sicht hat das alles Zeit, genieße Deinen Urlaub, ich habe das nur hier festgehalten, damit ich es nicht vergesse.

                    Gruß, Waldemar

                    Kommentar


                      Ich denke es ist am besten wenn man für den Pull-Request immer einen eigenen Branch macht. Immer wenn du auf den Branch einen neuen Commit machst, wird der automatisch dem Pull-Request hinzugefügt.

                      Zu den knx-Prods: Wenn du einfach nur eine knxprod haben willst, kannst du auch einfach mehrere Applikationsprogramme und Produkte in die knxprod packen. Dann muss man in ETS zwar immer noch das richtige auswählen, aber sollte ja kein Problem darstellen, oder? Es schein für das Appliationsprogramm noch ein Linkable Flag zu geben:
                      Linkable flag. Specifies that the application program may be loaded not only in devices with the specifies mask version, but also in compatible ones. See also Fixup.
                      Vielleicht reicht das ja schon.

                      Kommentar


                        Ich habe den Pull-Request zu Dpt 16 gemergt. Wenn du längere Texte brauchst könntest du Dpt 24.001 implementieren.

                        Kommentar


                          Hab die Änderungen mal kurz mit dem BME Sketch getestet, dieser liefert leider immer noch nur die 0-Werte.
                          Weiß jemand was für einen Datentyp die iaqSensor Lib liefert? Ich denke es liegt daran.
                          Grüße

                          Kommentar


                            Hi,

                            ich gebe zu, ich habe meine Änderungen zu DPT9 nur unter Linux getestet, sollte aber auf der Ebene unabhängig von der Plattform sein. Den BME kann ich mangels Hardware nicht testen...

                            Gruß, Waldemar

                            Kommentar


                              Hi Thomas,

                              Zitat von thesing Beitrag anzeigen
                              Linkable flag.
                              werde ich testen, danke für den Tipp. Mir geht es nicht um genau eine knxprod, das war blöd ausgedrückt. Mir geht es um eine einfache Debug-Umgebung. Ich denke eben an mein Logikmodul mit 50 Kanälen (SAMD, über TP angebunden), aufwändig parametrisiert und potentiell über längere Zeit bereits laufend. Nun stelle ich doch ein unerwartetes Verhalten fest, dass ich auch reproduzieren kann.

                              Einfach: Ich ziehe jetzt genau dieses Gerät von der TP auf die IP-Linie, programmiere mein Linux-basiertes IP-Gerät mit der ETS, schaue ob da der Fehler auch passiert und wenn ja, debugge ich komfortabel unter Linux bis ich den Fehler gefunden habe.

                              Kompliziert: Ich versuche, alle Parameter auf ein gleichartiges IP-Gerät (passende Version, aber eben nicht die gleiche) in der ETS zu übertragen (fehleranfällig) und versuche es dann unter Linux zu reproduzieren.

                              Noch komplizierter: Ich instrumentiere die firmware mit print-Ausgaben und versuche so den Fehler auf dem SAMD zu finden.

                              Ich versuche somit nur, den Komfort für mich zu erhöhen. Und dazu brauche ich eine Applikation, die unter TP und IP läuft. Nicht umsonst machst Du Deine Entwicklung vom Stack ja auch unter Linux. Ich kann damit leben, dass ich die MaskVersion für bau57B0 lokal bei mir anders zurück gebe als im allgemeinen Stack und verstehe auch, dass es nicht in den Stack rein gehört.

                              Gruß, Waldemar

                              Kommentar


                                Hi Thomas,

                                ich möchte nochmal auf das hier zurückkommen (ist lange her) - aber bitte erst nach Deinem Urlaub(!) lesen:
                                Zitat von thesing Beitrag anzeigen
                                restart: Das ist nicht soo einfach. Du musst erste eine mit TransportLayer.connectRequest eine Verbindung zum Ziel aufmachen. Die steht sobald das ApplicationLayer::connectConfirm kommt. Danach kannst du den restartRequest schicken. Bisher ist der der Stack noch nicht so ganz darauf vorbereitet. Ich muss mal schauen wie man das ansynchrone Zeug in C++ am besten macht.
                                Ich hab da was versucht... Letztendlich war ich erfolgreich und bin auch daran interessiert, dass die Realisierung auf die eine oder andere Weise im Stack einzieht, da mir die Funktion wichtig ist. Folgendes habe ich gemacht:
                                • Ich habe connect und disconnect in der knx_facade verfügbar gemacht (analog zu restart)
                                • Ich setze in meinem Coding im Abstand von 500ms (geht wahrscheinlich auch schneller, muss ich mal testen) die Befehle connect, restart, disconnect ab
                                • Der connect wird auf dem applicationLayer zu einem transportLayer->connectRequest gefolgt von einem deviceDescriptorReadRequest, da der connect selbst nicht beantwortet wird und erst der deviceDescriptorReadRequest einen ACK bekommt. Ob das so notwendig ist, weiß ich nicht, aber die ETS macht es genau so.
                                • Im transportLayer hab ich dann lange gebraucht (vor allem, weil ich bis zur KNX-Spec musste, um halbwegs zu verstehen, was da abgeht), da der Connect nie abgesetzt wurde. Letztendlich fehlt da in der StateEngine im A12 ein
                                  Code:
                                  _networkLayer->dataIndividualRequest(AckRequested, _connectionAddress, NetworkLayerParameter, SystemPriority, tpdu)
                                  steht auch so in der Spec 3.3.4 S. 20 bei A12: „send N_Data_Individual.req with T_CONNECT_REQ_PDU“.
                                  Im ApplicationLayer::ConnectConfirm fehlt ein
                                  Code:
                                  if (status) _connectedTsap = destination
                                An sich war es das und es funktioniert. Ist ja auch das, was Du damals geschrieben hast, nur brauchen normale Menschen etwas länger, um das zu verstehen und noch länger, um es zu realisieren.
                                Ich werte in der Anwendung nicht aus, ob der connect geklappt hat, aber wenn nicht, wird auch der reset nicht verschickt. Die Kommunikation ist identisch zu der von der ETS und die Geräte reagieren auch darauf. Meine Änderungen stören auch an keiner Stelle die Gruppen-Kommunikation oder die ETS-Programmierung – zumindest ist mir nichts aufgefallen.

                                Wenn man die Implementierung so lässt, dann würde man es der Applikation, die Deinen Stack nutzt, überlassen, die Reihenfolge und das Timing einzuhalten und auch sicherzustellen, dass nicht 2 connects parallel abgesetzt werden. Da ich wahrscheinlich der einzige Nutzer bin, ist die Frage, ob das für Dich OK wäre, es so zu lassen.

                                Eine andere Möglichkeit wäre natürlich, das Ganze auf dem ApplicationLayer zu realisieren und nur ein Kommando RestartDevice nach oben zu geben, aber dann bräuchte man eine Queue und müsste sauber auf die Connects/Disconnects reagieren und auf jeden Fall in loop() eingreifen. Wenn Du das unbedingt willst, würde ich mich daran wagen, aber lieber wäre mir die aktuelle Lösung. Ich verhindere konkurrierende Resets derzeit über ein if – ein konkurrierender Reset wird einfach um 2 Sekunden verzögert ausgeführt.

                                Ich kann gerne einen Pull-Request mit den Änderungen zusammenstellen (diesmal in einem neuen branch), ich hab das Coding ja da, ich wollte das aber prinzipiell vorher mit Dir geklärt haben und den anderen Beteiligten die Möglichkeit geben, auch was dazu zu sagen. Vielleicht gibt es auch andere Ideen...

                                Gruß, Waldemar

                                P.S.: Was mir beim testen noch aufgefallen ist: Wenn 2 Linux-Instanzen auf dem selben Rechner laufen, dann hören die sich gegenseitig nicht. Beide können senden und empfangen (werden z.B. von der ETS gehört und die ETS kann GA senden), aber nicht der eine zum anderen. Auf dem NetworkLayer kommen die Pakete gar nicht an. Da ich keine Idee habe, woran das liegen könnte, habe ich hier nicht weiter geforscht.

                                Kommentar

                                Lädt...
                                X