ARDUINO am KNX

[JuMi2006]

Hat sich schon jemand mit Power Savings beschäftigt? Bei mir wollte das auf die schnelle nicht. Standby ging, aber aufwachen nie .

EDIT:
Das Problem saß vor dem Monitor Aufwachen über Timer: Wartezeitverbrauch 5mA ... UART muss ich noch testen, aber nicht mehr heute.

[dreamy1]

Naja, ich hatte ja schonmal geschrieben dass ich den HTU21D als Feuchte- und Temperatursensor verwende...läuft per I2C und spuckt bei mir auch schon fleißg Werte aus auf dem Testbrett. Bald auch auf einem kleinen schnuckeligen TFT in der Blindabdeckung einer UP-Dose :-)

Gibts als fertiges "Sensorelement" mit 2,54mm-Stiftleistenanschluss...ich finds genial, zummal diesen damit schön "absetzen" kann:

https://www.sparkfun.com/products/12064

[greentux]

Gut man könnte jetzt den SMD Temp/Feuchte I2C auf einem Miniboard etwas vom Rest entkoppeln...
Aber der 1.50€ 2482 ist wohl eher was geeignetes. Zumal man dann das anschliessen kann, was mancher eh schon verbaut hat.

[l0wside]

Nur so aus Neugier:
Was hindert Dich daran einen I²C-Sensor zu verwenden?

Keine gute Idee, das habe ich durch. I2C-Sensoren kenne ich nur in SMD, d.h. mit gutem thermischem Kontakt zur Leiterplatte. Maxim schreibt in einem Datenblatt sinngemäß, dass der Sensor Leiterplatten- und nicht Lufttemperatur misst. Damit haben sie leider recht.
Mit DIL/DIP wäre es vermutlich ein bisschen besser, aber wohl nicht entscheidend.

Der DS18x20 im TO92 schwebt dagegen über der Leiterplatte und gibt eher die Lufttemperatur wieder als ein Sensor im IC-Gehäuse.

Was natürlich geht: DS2482 als Treiber über I2C. Oder einen PIC mit eingebauter Onewire-Schnittstelle nehmen

Max

[Tessi]

Über I2C wäre das aber sicherlich tausendmal schöner

Nur so aus Neugier:
Was hindert Dich daran einen I²C-Sensor zu verwenden?

[JuMi2006]

Hallo Max, Mailadresse ist ja bekannt
Dann könnte ich das die Tage mal auf dem Arduino testen. Ich hab da eigentlich selbst per Bitbanging und 1-Wire-Lib keine Sorge sofern man nicht alle 250ms die Sensoren ausliest. Wenn das alle 30-60 Sekunden geschieht hat ein Lesetelegramm eine Erfolgsquote von >99%. Über I2C wäre das aber sicherlich tausendmal schöner und nur 1,50€ teurer.

Grüße

[wintermute]

Ich kann nur noch mal anbieten, meinen Onewire-Code zur Verfügung zu stellen.

Ja, danke nochmal! Das waere sicherlich die feinste Loesung, aber mir fehlt grad die Zeit das umzubasteln
Irgendjemand anders vielleicht?

gruesse

[l0wside]

Ich kann nur noch mal anbieten, meinen Onewire-Code zur Verfügung zu stellen. Braucht nur einen Timer mit drei Interrupts (einschl. Überlauf). Keine Ahnung, ob der AVR so was hat (notfalls kann man auch einen Workaround finden und mit einem einzigen Timerinterrupt leben).

Max


Gesendet von meinem iPhone mit Tapatalk

[wintermute]

Also mir geht es primär um letzteres, in der Spezifikation bleibt man wohl auch unter Vollast.

Aber je mehr man heizt, desto mehr verfälscht man die Temperaturmessung, sofern der Sensor mit in (bzw. mehr auf) die UP-Dose soll.

Dann wird 3.3V/8MHz aber sicherlich trotzdem viel mehr bringen als den uC zwischendurch schlafen zu legen - wobei letzteres natuerlich dann noch das Sahnehaeubchen waere
Die genannten 175kWh beziehen sich ja auch - wie eben genannt - auf eine komplette Linie. Wenn der uC es tatsaechlich schaffen wuerde 50% seiner Zeit zu schlafen, dann reden wir hier von 100mW anstatt 200mW. Bei einer kompletten Linie vollgepackt mit Arduinos waeren das dann also satte 6.5W (grosszuegig gerundet) oder eben 57kWh im Jahr - das ist bestimmt ein Euro pro Monat oder eben 2Cent pro Arduino...

BTW: kennt das hier jemand?
http://xkcd.com/951/

Ich persoenlich taete in der Richtung 3.3V/8Mhz weiterarbeiten, das ist wesentlich sinnvoller als ein uC der nur schlaeft wenn kein Traffic auf dem Bus laeuft, denn das wird ohne SLEEP bestimmt das doppelte einsparen - probierts aus.

Und wo jetzt so viele Leute dran mitwerkeln und ich grad von sinnvoll schreibe: hat schon jemand eine Loesung fuer das Deaktivieren der Interrupts und dem daraus resultierenden KNX-Paketverlust beim 1wire-Auslesen gefunden? Vielleicht waers sinnvoll das erstmal rund zu klopfen, sonst wird es eh nie richtig funktionieren.

gruesse :: Michael

[Tessi]

Geht es jetzt darum den maximalen Stromverbauch gering zu halten um in der KNX-Spezifikation zu bleiben oder geht es darum Energie zu sparen?

Also mir geht es primär um letzteres, in der Spezifikation bleibt man wohl auch unter Vollast.

Aber je mehr man heizt, desto mehr verfälscht man die Temperaturmessung, sofern der Sensor mit in (bzw. mehr auf) die UP-Dose soll.

Außerdem mag ich den Gedanken nicht, das da eine relativ große Zahl an einzelnen Geräten auf dem Bus dauerhaft in der Summe dann doch schon einiges verbraten. Immerhin würde jede maximal belastete Linie pro Jahr über 175kWh verbrauchen. (In Zeiten, wo sogar der Standby-Verbrauch eines einzelnen TV-Gerätes an den Pranger gestellt wird und einige diese deshalb in Pausen sogar vom Netz trennen, darf man das gar nicht laut sagen) Da freue ich mich über jedes Gerät, das meistens eben nicht die volle Leistung zieht.

Ich habe den Pin nie gebraucht, der MSP430 kann wunderbar auf den UART reagieren und aus dem LPM aufwachen . Ich nehme aber an, dass der AVR das auch beherrscht.

In den Specs, die ich bisher gelesen habe wurde wakeup per UART leider nicht erwähnt...
Wäre zu prüfen, ob der hier verwendete AVR-Typ das kann.

[l0wside]

Das kann man ja sicher noch optimieren, auch die AVRs besitzen sicherlich Low-Power-Modi. Weis da jemand, ob die UARTs wakeupfähig sind? Oder ob eine BCU einen extra Wakeup-Ausgang besitzt?

Für die BCU kann ich nichts sagen. Der TPUART2 hat aber einen separaten Weckausgang, der kurz vor einer Übertragung den Pegel wechselt.
Ich habe den Pin nie gebraucht, der MSP430 kann wunderbar auf den UART reagieren und aus dem LPM aufwachen . Ich nehme aber an, dass der AVR das auch beherrscht.

Max

[wintermute]

Die Zeit zwischen Paketen ist für einen Microcontroller eine Ewigkeit. Es ist durchaus üblich, einen Controller in so einem Szenario schlafen zu schicken, zumal der TPUART ja erst wecken sollte, wenn das Paket vollständig ist.
Geweckt wird er dann durch ankommende Pakete und regelmäßig durch einen Timer, um die Temperaturen etc. auf den Bus zu schicken.

Geht es jetzt darum den maximalen Stromverbauch gering zu halten um in der KNX-Spezifikation zu bleiben oder geht es darum Energie zu sparen?
Wenn letzteres ist dein Einwand ok...

Ich kenne die Arduinos nicht, aber bei CMOS-Microcontrollern ist der Stromverbrauch grob proportional zur Taktfrequenz. Wenn er zwischendurch schlafen geht, relativiert sich das aber. Wenn er bei halbem Takt für die Wachphasen doppelt so lange braucht, verbraucht er im Endeffekt die selbe Energie.

siehe oben...

gruesse

[tuxedo]

Hi
@tuxedo: gute Idee - aber hast du eine protokollbeschreibung des ekeys? Ich glaube der ist (pseudo) verschlüsselt und das hat noch keiner zerlegt...
Also vorher das klären bevor du das am arduino lösen willst.
Was zumindest geht (hab ich gemacht) die 12v vom ekey helfen auch dem Transponder-arduino (da reicht die SV aus dem Bus nicht).
Also 4 Adern für ekey (SV und RS485) plus 2 Adern für den arduino/Knx-Bus.

Im eKey Thread wurde zuletzt behauptet dass da nix verschlüsselt sei.

Einen RS485 auf RS232 Adapter hab ich mir schon besorgt. Bisher scheitert es nur an der Zeit den Testaufbau auf der Baustelle zu machen. Gibt noch genug anderes auf dem Bau zu tun.
Die ursprüngliche Idee war das ganze mit einem raspberry pi zu machen und per Netzwerk das ganze auf den Bus zu bringen. Aber direkt KNX ware halt schöner.

Werde aber dran bleiben. Im Garagentür-schloss Thread kam mir gerade noch die Idee ein Keymatic mittels arduino an den Bus zu bringen. Gleiches dann auch gleich noch mit meinem Marantec Garagentormotor. Möglichkeiten gibt es viele. Aber solange der Rohbau noch herrscht ist die Freizeit für solche Basteleien ein wenig eingeschränkt. Will da aber auf jeden Fall dran bleiben....

[dschwert]

Solange der Arduino aber permanent auf KNX-Kommandos reagieren soll ist das eher muessig, denn dann beendet er den Sleep-Mode ja eh bei jedem Paket (egal an wen es geht).

Die Zeit zwischen Paketen ist für einen Microcontroller eine Ewigkeit. Es ist durchaus üblich, einen Controller in so einem Szenario schlafen zu schicken, zumal der TPUART ja erst wecken sollte, wenn das Paket vollständig ist.
Geweckt wird er dann durch ankommende Pakete und regelmäßig durch einen Timer, um die Temperaturen etc. auf den Bus zu schicken.

5V/16MHz zu 5V/8Mhz werden - vermute ich - nicht soviel bringen, hab ich aber selber noch nie ausprobiert...

Ich kenne die Arduinos nicht, aber bei CMOS-Microcontrollern ist der Stromverbrauch grob proportional zur Taktfrequenz. Wenn er zwischendurch schlafen geht, relativiert sich das aber. Wenn er bei halbem Takt für die Wachphasen doppelt so lange braucht, verbraucht er im Endeffekt die selbe Energie.

Gruß,

Dietmar

[ThorstenGehrig]

Hi
@tuxedo: gute Idee - aber hast du eine protokollbeschreibung des ekeys? Ich glaube der ist (pseudo) verschlüsselt und das hat noch keiner zerlegt...
Also vorher das klären bevor du das am arduino lösen willst.
Was zumindest geht (hab ich gemacht) die 12v vom ekey helfen auch dem Transponder-arduino (da reicht die SV aus dem Bus nicht).
Also 4 Adern für ekey (SV und RS485) plus 2 Adern für den arduino/Knx-Bus.

@all: mit dem Leonardo und der 2 seriellen Schnittstellen ist schon genial. Das programmieren über USB ist auch "idiotensicherer" als per USB-TTL fummeln zu müssen - und man kann programmieren während man am KNX Bus ist. Also nur gute Gründe für den kleinen Leonardo. (Bestellt - und wer nimmt jetzt meine "alten"?)

Gruß
Thorsten