KNX-Multisensor

[RoKHB]

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.

Da sehe ich kein Problem. Die ETS ist ja auch nicht so schlank
Der C++ Compiler sollte dann was freies sein.

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.

Ich denke das passt. Muss doch eh für jede Plattform extra kompiliert werden. Der Präprozessor packt das schon.

Robert

[l0wside]

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

[RoKHB]

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

[l0wside]

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

[Robert]

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

[l0wside]

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

<?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

[Robert]

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!?

[l0wside]

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

[Robert]

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

[sabinellina]

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 ?

[Robert]

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

[l0wside]

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

[sabinellina]

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. :-(

[RoKHB]

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

[dmxled]

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