Ankündigung

Einklappen
Keine Ankündigung bisher.

KNX-Multisensor

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

    KNX/EIB KNX-Multisensor

    Hallo zusammen,

    nachdem ich meine 1-Wire-Multisensoren nie so recht zum Laufen bekommen habe (siehe hier), habe ich mich daran gemacht, eine Alternative auf KNX-Basis zu entwerfen.
    Eigentlich wollte ich das Thema noch eine Weile im stillen Kämmerlein behalten, aber diverse PMs haben signalisiert, dass das Interesse doch da wäre. Deswegen nun hier der aktuelle Stand.
    -----------------------------------------------------------------------------

    Anforderungen waren:
    • Identische Abmessungen wie der Wiregate-Multisensor, d.h. muss in den Berker Sensoreinsatz passen.
    • Feuchte- und Temperaturmessung mit Toleranz 2% Feuchte und 1°C
    • Keine Bastellösung à la Freebus, sondern Einsatz des TPUART2
    • Geringe Stromaufnahme (Ziel 1 mA auf der Busleitung) - das ist zwar immer noch schlechter als der Wiregate-Multisensor, dafür entfällt der USB-Bustreiber.

    Ein Muster der Leiterplatte existiert schon und liegt in drei Exemplaren neben mir. Parameter:
    • HIH5030 (Honeywell) für die analoge Feuchteerfassung
    • PCT2075 (NXP, es gibt einen pinkompatiblen Baustein von Maxim) für die Temperatur.
    • Mikrocontroller ist der MSP430F5408 von TI, mit dem ich zum einen Erfahrung habe, zum anderen ist er in der Stromaufnahme richtig gut (im Ruhezustand im µA-Bereich).
    • Anschluss an den KNX über einen TPUART2.

    Auf der LP sind noch einige Dinge zu tun, die HW wird sich sicher noch ein-, zweimal ändern:
    • Den PCT2075 habe ich im HWSON8 (beinloses Winzgehäuse) verbaut, das wird sich noch auf SO8 ändern, was man auch als Normalmensch löten kann.
    • Der Stützkondensator für den Schaltregler im TPUART2 ist aus der Applikationsbeschaltung des Siemens-Demoboards übernommen und als 330µF-Elko im Alubecher völlig überdimensioniert. Ziel ist, am Ende auf etwas schön Flaches zu kommen, 10µF in 1210 oder so. Die Spule kann sicher auch noch kleiner werden als die aktuell eingeplanten 68µH.
    • Ich habe Zweifel, dass der aktuelle Stand tatsächlich in den Berker-Sensoreinsatz passt, da werde ich noch das eine oder andere hin- und herschieben müssen.

    Momentan sieht die LP aus wie im Anhang zu sehen. Ich bin gerade dabei, die erste zu bestücken - leider ist Opternus (Lieferant des TPUART2) nicht eben fix, ich warte noch aufs Angebot.


    Die HW kriege ich hin, auch die Low-Level-Programmierung des MSP430. Ich würde mich aber über jeden Mitstreiter auf SW-Seite freuen.
    To Do dort:
    • KNX-Kommunikation. Die Low-Level-SW liefert einen Datenstrom (in Form einer deque) für die Kommunikation mit dem TPUART2 und erwartet einen ebensolchen zurück.
      Es gibt hier diverse Vorarbeiten, auf die man aufsetzen kann:
      • Robert hat wohl einen Stack implementiert, aber aus Patentbedenken heraus m.W. nicht veröffentlicht.
      • Bei Freebus gibt es auch so etwas wie einen Stack, bei dem man den Low-level-Teil entsprechend austauschen müsste. Allerdings ist mir die Freebus-Lizenz nicht wirklich sympathisch, mir würde eher LGPL vorschweben.
      • Einen Freebus-ähnlichen Ansatz gibt es auch noch hier.

    • Umsetzen der Sensor-Rohdaten, d.h. Kompensation der Feuchtesensor-Kennlinie und Umschlüsseln der Temperatur- und Sensorwerte auf DPT9.
    • Schreiben der physikalischen Adresse (das gehört eigentlich noch zum KNX-Stack)
    • Konfigurationsprogramm auf PC-Seite, das mittels Memory Write (APCI 0b101000) die Konfigurationsdaten (Gruppenadressen und Sendeintervall) in den Sensor schreibt. eibd hat eine passende Funktion, der Aufwand sollte also einigermaßen überschaubar sein. Für Windows kann man entweder etwas zu Fuß stricken oder auf Falcon zurückgreifen.
      Eine Parametrierung über die ETS strebe ich im Moment nicht an, da muss dann ein Dummy-Device reichen. Darüber kann man nachdenken, falls es je eine kommerzielle Version davon geben sollte, aber das ist momentan bestenfalls Zukunftsmusik.

    Der MSP430F5xxx braucht leider den "FET UIF" von TI zur Programmierung, der kostet um die 100 EUR. Angeblich geht es auch mit dem (billigeren) EZ430-Stick, das habe ich aber nicht zum Laufen gebracht.

    Ich bin jetzt erst mal eine Woche im Urlaub und dort weitab von E-Mails. Melde mich dann wohl am 10.9. wieder.

    Max
    Angehängte Dateien

    #2
    HI
    Klingt sehr spannend
    Was ist mit der ETS Applikation ?
    Gruss
    Oli

    Kommentar


      #3
      Moin,

      sowas ähnliches hab ich schon als Protoyp laufen, allerdings mit dem China AM2302. Das Modul ist mit ATMega168 und wird auf den UP117/12 BTM gesteckt.
      Programmiert wird mit AVR Dragon und einer kleinen Adapterplatine.
      Aus Zeitmangel ruht das ganze aber noch die nächsten Wochen. Die Software kann nur an feste GA in festen Zeitabständen Feuchte und Temperatur senden.

      Grüße
      Robert
      Angehängte Dateien

      Kommentar


        #4
        Moin l0wside,
        ich bin auch auf der Suche nach einem Multi-Sensor, der die Lüftung der Bäder triggert.
        Somit finde ich dein Projekt grundsätzlich gut. Ich hatte schon mal eigene Überlegungen angestellt. Es gibt jemanden, der hat einen Sensirion Sensor über einen Attiny an den Bus gebracht. Das hätte ich adaptiert/ aufgebohrt. (Leider finde ich es grad nicht mehr)
        Hast du eigentlich mal über eine CO2 Messung innerhalb des Sensors nachgedacht ?
        Wäre ein alternativer µC mit einer günstigeren Entwicklungsumgebung nicht besser gewesen? (AVR ?)
        So ist die Schwelle, des Einstieg schon etwas hoch.

        Gleichzeitig stellt sich mir die Frage, ob das Projekt nicht schon fast obsolet ist, den der MDT-Sensor ist bald erhältlich (leider auch ohne CO2) und der wird komfortabler einzubinden sein.
        Hast du schon ungefähr einen Preis (Ganz grob, Bauteil-Level) für deinen Sensor?

        Danke
        Gruß Stefan

        Edit: Hab eben gesehen, das der MDT gar keine Feuchte hat. :-(

        Kommentar


          #5
          CO-Sensor ist bis jetzt nicht dabei, Platz wäre aber prinzipiell noch auf der Leiterplatte - wäre dann rev 0.6...

          Hat jemand eine Empfehlung für einen passenden Baustein? Vorzugsweise I2C oder analog, ich will nicht auch noch SPI auf dem Board haben.


          Wegen Programmierung: es wird vsl. die Möglichkeit geben, über den Bus neu zu flashen. Der Code ist aber noch in der Mache.

          Max

          Kommentar


            #6
            Schlachte einfach und unkompliziert einen Air Wick Fresh Matic - günstiger kommst du nicht an den Sensor und hinterher kann man die immer noch teuer von Applied Sensors direkt kaufen.

            Grüße
            Robert

            Kommentar


              #7
              Alles, was ich bisher als CO2 Sensoren gesehen habe, verbrauchte entweder zuviel Power oder war unbezahlbar.
              Die optischen benötigen wenig Leistung, sind aber meistens als vorintegrierte Module (Preprocessing, Interface, etc.) recht kostspielig.

              Tja und die anderen Sensoren bekommt man aus dem Bus nicht gepowered.

              Mit so einem AirWick-ding ist echt eine Idee ...

              Hast du schon mal eines geschlachtet ?

              Kommentar


                #8
                IAQ-2000 - Mikrocontroller.net

                Geruchssensor - Air Wick Fresh Matic - Mikrocontroller.net

                Bei weiteren Fragen bitte neuen Thread machen - der hier gehört Max Multisensor.

                Ach ja, mal on-topic: Solange nicht eine klare Strategie vorhanden ist, wie den einzelnen Kommunikationsobjekten die GAs zugewiesen und Parameter verändert werden können sehe ich weitere Sensoren als "lustiges Beiwerk" an. Die Sensoren bindet man "mit links" ein - aber wenn jeder hinterher sich die Firmware mit seinen GAs einkompilieren muss...

                Kommentar


                  #9
                  Zitat von Robert Beitrag anzeigen
                  Solange nicht eine klare Strategie vorhanden ist, wie den einzelnen Kommunikationsobjekten die GAs zugewiesen und Parameter verändert werden können sehe ich weitere Sensoren als "lustiges Beiwerk" an. Die Sensoren bindet man "mit links" ein - aber wenn jeder hinterher sich die Firmware mit seinen GAs einkompilieren muss...
                  Nein, so ist das nicht gedacht. Ich weiß, dass das bei deinem Garagentor-Interface ein Problem war.
                  • Die PA-Programmierung ist standardisiert, das soll hier auch nach dem Standard funktionieren. Das macht mir keine allzu großen Sorgen.
                  • Die Zuordnung der KO ist Sache der Applikation. Hierfür gibt es im Protokoll A_Memory_Write auf Layer 7. Dazu braucht es dann ein entsprechendes Gegenstück auf PC-Seite. Ich hoffe, dass entweder der eibd oder Falcon hier Unterstützung bietet. Kennt sich hier jemand aus? Der Stack auf Sensorseite wird das können.
                    EDIT: Falcon sieht auf den ersten Blick grausam aus, und eibd endet auf Layer 4, d.h. die APDUs muss man sich selber bauen. Hat jemand der Anwesenden Ambitionen, sich hier einzubringen?

                  ETS-Unterstützung ist nur langfristig auf der Roadmap, da wird´s dann nämlich teuer.

                  Max

                  Kommentar


                    #10
                    Genau - alles richtig.

                    Natürlich kannst du die Sachen auch per Shell-Script und MemoryWrite reindengeln. Aber genau da wäre es ja schön, wenn es eine Lösung gäbe, die breit über alle Bastellösungen portable wäre. Den ETS-Support sehe ich als quasi unmöglich an wenn man sich nicht gerade hauptberuflich selbstständig machen will...

                    Hast du mittlerweile die TPUARTs erhalten?

                    Grüße
                    Robert

                    Ne, vom Falcon gibts doch sogar Demo-Apps die ich in Visual Studio sogar erfolgreich kompilieren und modifizieren konnte!?

                    Kommentar


                      #11
                      TPUARTs sind da.
                      Was ist an MemoryWrite gedengelt? Die ETS macht es auch nicht anders.

                      Mir schwebt eine Konfigurationsdatei vor, XML, JSON, INI oder wasauchimmer als Format, die Key-Value-Paare enthält. Z.B.:
                      Code:
                      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
                      <eib-config-data version="0.1">
                          <manufacturer>Klimbim&Co</manufacturer>
                          <application>Multisensor</application>
                          <version="0.5">
                          <parameters>
                              <param type="uint16" name="interval">
                                  <longname>Transmit Interval (Temperature)</longname>
                                  <min>1</min>
                                  <max>3600</max>
                                  <memaddr>0x0fb0</memaddr>
                              </param>
                          </parameters>
                          <commobjects>
                              <co name="temp">
                                  <longname>Temperature</longname>
                                  <id>10</id>
                                  <dpt>9</dpt>
                              </co>
                              <co name="hum">
                                  <longname>Humidity</longname>
                                  <id>20</id>
                                  <dpt>9</dpt>
                              </co>
                          </commobjects>
                          <associations>
                              <memaddr>0x0fc0</memaddr>
                              <count>32</count>
                          </associations>
                      </eib-config-data>
                      [irgendwas habe ich bestimmt vergessen]

                      Max

                      Kommentar


                        #12
                        Zitat von l0wside Beitrag anzeigen
                        Was ist an MemoryWrite gedengelt?
                        Mittlerweile geht es eher richtung PropertyRead/-Write und weg vom starren Speichermodell ("Memory....) der BCU1/BCU2 Generationen. Die nämlich dauerhaft auf allen Geräte(plattformen) abzubilden ist Unsinn und läuft dann eh auf ein Mapping hinaus.

                        Ansonsten: Mit XML etc. hatten wir ja schon mal, siehe https://knx-user-forum.de/333464-post20.html. Da hatte ich das mit memread/wwrite versus Properties übrigens auch schon mal geschrieben. Wäre natürlich schön wenn es einer anpackt.

                        Grüße
                        Robert

                        Kommentar


                          #13
                          Klingt plausibel. Ich kann mit beidem leben, vom Protokoll her ist PropertyRead/Write sowieso einfacher.

                          Findet sich hier jemand, der sich um die PC-Seite kümmern mag? Meine Ambitionen, mich mit Falcon oder eibd sowie Java- oder wasauchimmer-Programmierung herumzuschlagen, sind sehr überschaubar. Ich fürchte aber, dass ich nicht daran vorbeikomme.

                          Max

                          Kommentar


                            #14
                            Zitat von l0wside Beitrag anzeigen
                            Findet sich hier jemand, der sich um die PC-Seite kümmern mag? Meine Ambitionen, mich mit Falcon oder eibd sowie Java- oder wasauchimmer-Programmierung herumzuschlagen, sind sehr überschaubar. Ich fürchte aber, dass ich nicht daran vorbeikomme.
                            Max
                            Tja, irgendwer muss ja mal anfangen. Wenn du das mit Visual C# 2010 Express und Falson hinbekommst, dann könnte ich da vielleicht auch ein paar Stunden reinstecken.
                            Für ne plattformübergreifende Lösung würde sich wohl Qt und C++ anbieten.
                            Java wäre nix für mich.

                            Robert

                            Kommentar


                              #15
                              Mir ist es ziemlich egal.
                              • Qt hat zwei Vorteile: ich habe schon damit gearbeitet, und es ist cross-platform. Nachteil: ein Hello World hat schon > 5 MB.
                              • Visual C++ Express habe ich gestern mal runtergeladen. C# fange ich aber nicht an.
                              • Vielleicht wäre am Anfang ein Kommandozeilentool (knxpropwrite oder so) gar nicht verkehrt.

                              Cross-Platform wird sowieso nur eingeschränkt gehen: Falcon ist Windows-only, und eibd ist Unix-only. Die GUI könnte man als Cross-Platform hinbekommen, das Backend eher nicht.



                              Max

                              Kommentar

                              Lädt...
                              X