KNX-Multisensor

[l0wside]

Seit gestern abend funktioniert PropertyWrite und PropertyRead (die sind notwendig, um das Gerät über den Bus zu konfigurieren).

Jetzt fehlen nur noch zwei Features:

• Die Applikation muss die per PropertyWrite gesetzten Werte auch tatsächlich verwenden
• Flashen über den Bus

Ich bin optimistisch, das in den nächsten Tagen hinzubekommen.



Die Temperaturabweichung wird vorläufig per fixem Offset (einstellbar über PropertyWrite) kompensiert. HW rev 0.7 bekommt dann einen DS18B20.



Max

[JuMi2006]

Taugt 0.6 denn wenigstens um sich schon mal die Programmierscripte zu machen? Dann hätte man einen gewissen "Vorsprung durch Rückschlag" Würde mich der Sache dann mal versuchen anzunehmen...wird vorher zwar etwas Lektüre nötig sein aber das wäre es wert.

Grüße

[l0wside]

Verflixte Sensoren

Zur Hardware

Ich bin genervt. Entgegen meiner Erwartung nimmt die Schaltung um die 3 mA vom Bus auf, also knapp 100 mW. Das reicht für eine Eigenerwärmung von 2,5°C - 3°C, was das Temperatursignal ziemlich unbrauchbar macht.

Ich werde wohl doch auf einen analogen Sensor (im TO-92 gibt es sonst nur noch Onewire, und das müsste ich per Bitbanging implementieren - nein danke) umsteigen müssen. Merde. Schon wieder neue Leiterplatten (dann wohl v0.7)

Max

[greentux]

Wenn ein wenig Bash reicht, dann sollte man vl. das erstmal so lassen.
Weiterhin denke ich immer noch, das man aus sh.py heraus vl. die Konfiguration vornehmen könnte... automatisiert.

[l0wside]

Der Ansatz gefällt mir - würde die Portabilität mit eibd gut kombinieren. Ich würde aber auf den Browser verzichten, python+tkinter ist portabel.

Max

[JuMi2006]

Ich würde da eher php und perl sehen, python geht sicherlich auch.
Um es noch einfacher zu machen könnte man das Tool in 2 Teile splitten:

1. Config erzeugen -> Im Browser über ne definierte Eingabemaske
2. Config einspielen -> shell-script "write_to_rom.sh --config=neu.txt"

Die config könnte man sogar in einem interaktiven Shell-Script erzeugen lassen. Damit sind wir zwar erstmal nur bei der Kommandozeile aber da kann dann wenig schief gehen.

Grüße

[l0wside]

KNX Programmiertool - welche Oberfläche?

Hallo zusammen,

es wird langsam Zeit, sich mit der PC-Seite der Gerätekonfiguration zu beschäftigen. Im ersten Schritt ist die Verwendung der fix und fertig vorhandenen eibd-Tools (writeaddress, memwrite und xpropwrite) am einfachsten. Das heißt im Gegenzug aber auch, dass ein Linux-System zwingend notwendig ist (eibd auf Windows funktioniert m.W. nicht).

Welche Oberfläche ist denn am sinnvollsten?

• Reine Kommandozeile, Parameter aus einem HOWTO. Reicht für den Anfang sicher aus, ist aber keine Dauerlösung.
• Python/Tkinter. Wäre erst mal mein Favorit, da prinzipiell cross-platform. Ist aber blöd für all diejenigen, die Linux nur auf einem Embedded-Rechner betreiben und ansonsten Windows einsetzen - da braucht es dann einen X-Server auf Windows-Seite (bis sich jemand erbarmt und Falcon integriert)
• Integration z.B. in Webmin. Wäre sicher hilfreich für alle CommunityGate/Wiregate-Besitzer. Nachteil: wer keines hat, wird nicht deswegen extra Webmin installieren wollen.
• Eingebauter Webserver: sehr flexibel. Nachteil: man muss im Browser mit Adressen jonglieren, und man muss in Python (oder was auch immer) HTML generieren.

Hat noch jemand eine bessere Idee (oder will gar sich an Falcon machen)?

EDIT: Im Anhang eine Anregung, wie ich mir eine GUI vorstellen könnte.

Max

P.S.: Zur Hardware
Sie wird - Version 0.5 ist zwar immer noch nicht ganz fehlerfrei, funktioniert aber stabil. Die PA lässt sich inzwischen über den Bus programmieren. Ich hoffe, dass bis Ende der Woche sich auch die GA über den Bus setzen lassen und das Gerät sich über den Bus neu flashen lässt.
Wenn das alles tut, mache ich mich auf Testersuche.

[l0wside]

Mach doch auch ein einfaches Aufsteckmodul für den UP117, so wie in meiner Version. Ohne den TPuart2 Chip sollte das doch einfach zu löten sein.

• Ich kann den TPUART löten, es ist nur etwas spaßbefreit.
• Mit dem UP117 wird der ganze Spaß am Ende vermutlich doppelt so teuer
• Im Lastenheft stand auch "Berker Sensoreinsatz". Das wird mit dem UP117 nichts.

Max

[greentux]

Und die Befestigung etc. wäre damit auch gegeben.

[RoKHB]

Mach doch auch ein einfaches Aufsteckmodul für den UP117, so wie in meiner Version. Ohne den TPuart2 Chip sollte das doch einfach zu löten sein.

[l0wside]

Ja. Teuer sind vor allem TP-UART (fast 7 EUR) und Feuchtesensor (auch in dem Rahmen). In der Summe sind die reinen Bauteilkosten um die 20 EUR.

Ich muss mir noch ein Modell für die Weitergabe überlegen. Inzwischen stecken ein paar hundert Stunden Arbeit drin. Bei den ersten paar Prototypen ist mir das Geld egal, aber wenn das erste Dutzend mal erreicht ist, ist professionelles Bestücken angesagt, sonst werde ich wahnsinnig. Und das kostet leider Geld.

Interesse frage ich aber erst dann ab, wenn ein halbwegs stabiler Zustand erreicht ist. Im Moment sieht es so aus, dass Platine #4 mit einem unauffindbaren Kurzschluss über den Jordan ist und ich #5 erst mal aufbauen muss.

Max

[greentux]

DAnn hier nochmal Max. Hast Du schon eine Bauteilekalkulation?

Gruß

[greentux]

Oder man laesst die Config aus so Backends wie smarthome.py rausfallen und schreibt sie weg...

[JuMi2006]

Ich kann zwar sonst nicht viel beitragen, verfolge das Thema aber gespannt.
Ich glaube auch nicht dass es (vorerst) eine wirkliche Notwendigkeit für die GUI gibt, ich könnte mir allerdings auch eine einfach html-Oberfläche vorstellen hinter der ein Script die passende config zum programmieren baut.

[l0wside]

Ich habe gestern nochmal darüber meditiert. Ich denke, es wird für den Start nur ein (bzw. zwei) Kommandozeilentools auf eibd-Basis, lauffähig unter Linux, geben.

Kurze Recherche: Martin Kögler hat das alles schon geschrieben.

• xpropwrite und xpropread für die Konfiguration
• mwrite und mread für das Flashen über den Bus

Damit ist der PC-Aufwand nur noch ein nice-to-have: auf eine GUI kann man notfalls auch erst mal verzichten. Das können andere besser als ich



Gruß,


Max