ARDUINO am KNX

[intelligente Haustechnik]

Dann scheint die "Serial" ein Software-Serial über USB zu sein. Ich kann mit dem kleinen Ding nämlich gleichzeitig auf "Serial" am Rechner debuggen. Mit "Serial1" spreche ich dann die Pinouts an ... so hatte ich es auch irgendwo gelesen.

Das stimmt, siehe Link

Jens

[l0wside]

Summe: 41mA aus der BCU - perfekt!

Das sind 200 mW plus BCU-Eigenverbrauch (ich tippe mal auf 50-100mW), was eine Temperaturmessung in der Dose grenzwertig werden lässt. Die Sensoren brauchen nahezu nichts (µA-Bereich), der Arduino genehmigt sich also einen großen Schluck aus der Pulle.

Ich habe hier rund 0,7K Temperaturdifferenz zwischen Doseninnerem und freifliegend in der Luft, bei einer Verlustleistung von rund 100mW. Macht 7K/W an thermischem Widerstand (im Berker-Sensoreinsatz).

Max

[tuxedo]

Pro mini und Pro micro müssten bis auf 1-2 millimeter gleichgroß sein.
Die haben aber nur einen TP-Uart - und damit wirds mit dem Hardware-Debuggen eng.
Zum entwickeln von Projekten kann man aber leicht einen Mega verwenden - und wenn der Code passt dann einfach auf den kleinen Anpassen.
Wofür brauchst du ein RS485? Müsste aber per SoftwareSerial funktionieren - nur in klein hab ich das noch nicht gesehen.

Gruß
Thorsten

Mein an der Haustür hängender eKey Fingerscanner soll RS485 sprechen. Dachte da in Zusammenhang mit dem Arduino an ein Low-Cost-KNX-eKey Adapter der die Identifikation (Benutzer-Nr, Finger-Nr) des über den Scanner gezogenen Fingers auf den Bus bringt.

Viel "Traffik" ist da nicht zu erwarten. Evtl. klappt's hier auch mit einem Software-Serial über die normalen IO Ports. Aber zwei echte UARTs wären mir so aus dem Bauch heraus lieber.

Software-Serial zum debuggen wäre wohl auch möglich. Auch hier ist nicht allzuviel Traffik zu erwarten.

So wie ich das bis jetzt recherchiert habe gibt's entweder einen UART (dann ist der Arduino sehr klein), oder gleich 4 (dann ist es für mich viel zu groß. Will das Resultat in ein 1-2TE REG Gehäuse packen).

[Tessi]

der Arduino genehmigt sich also einen großen Schluck aus der Pulle.

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?

[wintermute]

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?

Die verfuegbaren Sleep-Modes haengen vom verbauten uC ab, eine Uebersicht ist zB hier zu finden:
<avr/power.h>: Power Reduction Management

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

Am sinnvollsten waere es einen 3.3V Arduino zu verwenden, der hat auch nur den halben Takt. Von 5V/16Mhz auf 3.3V/8Mhz zu wechseln wird die Stromentnahme etwa vierteln, vielleicht kommt sogar noch etwas mehr bei rum (also weniger ).
5V/16MHz zu 5V/8Mhz werden - vermute ich - nicht soviel bringen, hab ich aber selber noch nie ausprobiert...

gruesse :: Michael

[greentux]

Hier
Electronics : Microprocessors : Power saving techniques for microprocessors
steht ggf auch noch was...

[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

[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

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

[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

[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

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

[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

[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]

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