Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[hexenmeister]

Ein Paar µA für die Sensoren, AVR, CC1101 kommen auch noch dazu. Und periodisch aufwachen muss der AVR auch noch. Somit bekommen wir hier bestimmt keine 44 Jahre hin

Das ist mir schon klar. Auch dass die Batterien Selbstentladung haben.
Sollte ja eine Vergleichrechnung sein.

Spart einen Pin und trotzdem Energie.

Klingt nach einer guten Wiederverwertung, ganz im Sinne der Nachhaltigkeit
Einen Nachteil sehe ich auch nicht.

Grüße,

Alexander

[trilu]

Jetzt weiss ich wieder was das Problem an Heißkleber auf Platinen war

Also, habe gerade den SHT10 auf den I2C Bus gepackt - A4 data, A5, sck.
Es geht teilweise...

Die Arduino Wire library kennt nur ein Wire.begin(), von da an ist Schluss mit der Temperatur und Feuchte.
Ein Wire.end() kennt die Library nicht. Wenn man aber den I2C Bus manuell wieder ausschaltet, dann geht der
SHT10 auch wieder.
Ist aber derzeit ein gefrickel!
Vielleicht sollten wir ganz weg von HW I2C und Bitbang machen?

[jjf]

Da ich mich parallel noch mit HM-Wired (RS485) beschäftige hatte ich hier auch eine RS485-Version vorgesehen.
Gruß
Dirk

Zu RS485 habe ich Fragen:
1. HM-Protokoll:
Ich habe "HS485_Protokoll.pdf" und "HMW RS 485 Protokollbeschreibung_87.pdf" gefunden.
Gibt es noch weitere Infos?

2. Das Protokoll ist Multi-Master fähig.
Gibt es Einschränkungen vom Protokoll 2 FHEM-Rechner auf einen RS485-Bus zugreifen
zu lassen (kein fhem2fhem).

3. Gibt es intellektuelle Rechtsansprüche, die einem das Leben
schwer machen können?

Zu RS485 habe ich auch eine Meinung.
Gesamtkosten sind minimal, weil das Produkt aus:
Zuverlässigkeit * Leistungsverbrauch * Preis pro Knoten
optimal ist.

Gruss,
Joachim

[Dirk]

Jetzt weiss ich wieder was das Problem an Heißkleber auf Platinen war

Der gute alte Heißkleber

Die Arduino Wire library kennt nur ein Wire.begin(), von da an ist Schluss mit der Temperatur und Feuchte.

Schau mal in twi.h twi_stop() oder twi_releaseBus() könnten das übernehmen.

Vielleicht sollten wir ganz weg von HW I2C und Bitbang machen?

Das währ auch noch ein Weg.

Was hältst du davon den Pin für den Config-Taster und für Enable des Spanungsteilers gemeinsam zu verwenden?
Dann würde ich das noch entsprechend umstricken.

Ich habe "HS485_Protokoll.pdf" und "HMW RS 485 Protokollbeschreibung_87.pdf" gefunden.
Gibt es noch weitere Infos?

Das sind alles Infos die ich derzeit dazu zusammentragen konnte. Ansonsten noch die XML-Files aus der CCU-Firmware. Daraus kann man den Aufbau werden der Datenframes ableiten.

Gibt es Einschränkungen vom Protokoll 2 FHEM-Rechner auf einen RS485-Bus zugreifen
zu lassen (kein fhem2fhem).

Ich habe hier aktuell eine CCU und FHEM am Bus. Das funktioniert, ist aber so nicht vorgesehen.
Probleme gibt es ggf. wenn beide Zentralen Nachrichten quotieren wollen. Da müsste man sich noch was einfallen lassen.

3. Gibt es intellektuelle Rechtsansprüche, die einem das Leben
schwer machen können?

Zumindest das Vorgängerprotokoll HS485 war veröffentlicht. HM-Wired ist nur eine Erweiterung dessen.
Mir fällt grade nicht ein wo man da ansetzen könnte.

Gruß
Dirk

[trilu]

Was hältst du davon den Pin für den Config-Taster und für Enable des Spanungsteilers gemeinsam zu verwenden?
Dann würde ich das noch entsprechend umstricken.

Um ehrlich zu sein, nicht ganz so viel

Der Config Taster basiert ja auf einem Pin Interrupt. Ich weiss nicht, wie sich der verhält wenn der Pin anderweitig verwendet wird.
Den Interrupt brauchen wir aber um das Device beim Tastendruck aus dem Schlaf zu holen...

Die twi.h lässt sich nicht so einfach einbinden, das sie in dem utility Ordner zur Wire.h ist.
Bohhh, diese Arduino Hürden

Viele Grüße
Horst

[Dirk]

Der Config Taster basiert ja auf einem Pin Interrupt. Ich weiss nicht, wie sich der verhält wenn der Pin anderweitig verwendet wird.

Klar, der muss auch an bleiben.
Für das Auslesen vom ADC muss man den Interuppt kurz deaktivieren, dannach wieder aktivieren. Im Prinzip ganz einfach
Aber das müssen wir ja nicht machen. Währ schön weil man noch ein Pin frei hat.

Die twi.h lässt sich nicht so einfach einbinden, das sie in dem utility Ordner zur Wire.h ist.

Wire.h benutzt twi.h Daher sollte das eigentlich funktionieren.
Ansonsten die I2C-Register "zu Fuß" ein- und abschalten?

[Mr. P]

Hej,

nachdem der Thread-Titel nicht ganz sooo selbsterklärend ist, hab ich mich erst heute dazu entschlossen, einen Blick zu riskieren und mit jeder Seite stieg die Begeisterung.

Mit den Dingern könnte ich endlich meine S300TH in Rente schicken und somit FS20 bei mir endgültig "abschalten".

Daher würde ich bei den interessierten Personen für solche Teile auf alle Fälle auch mit aufzeigen.

Was genau würde mich interessieren?
1x Außen: Da genügt wohl T/H/B
Innen wird es schon interessanter: auf alle Fälle auch T/H. Über den Nutzen der Helligkeit (B) für jeden Raum bin ich mir noch nicht so ganz im klaren (würde mich interessieren, was ihr mit einer solchen "Funktion" anstellen würdet). Aber Luftgüte und ggf. auch ein Wassermelder wären im Falle der Verfügbarkeit sehr hilfreich. Also für innen wären dann 6 Stück interessant.
Letztendlich würde mich natürlich noch interessieren, ob sich die Module als externe Temp-Sensoren für die RTs nutzen lassen... das wäre gewissermaßen das Sahnehäubchen.

Great Job... Immer weiter so! 

[hexenmeister]

Über den Nutzen der Helligkeit (B) für jeden Raum bin ich mir noch nicht so ganz im klaren (würde mich interessieren, was ihr mit einer solchen "Funktion" anstellen würdet).

Na zum Bleistift:
Rolladen werden nach dem Wert der Helligkeit draußen heruntergefahren. Wenn drinne Licht angemacht wird, dann weden die Rolladen etwas früher heruntergefahren (ggf. noch abhängig von dem Bewegungsmelder draußen )
LG

Alexander

[jjf]

Zumindest das Vorgängerprotokoll HS485 war veröffentlicht. HM-Wired ist nur eine Erweiterung dessen.
Mir fällt grade nicht ein wo man da ansetzen könnte.
Gruß
Dirk

Zitat von http://www.elv.de/output/controller.aspx?cid=307:
"Das wesentliche Know-how der Eigenentwicklungen ist durch Patente, Geschmacks- und Gebrauchsmuster geschützt."
Hat die schon jemand gelesen?

Gruss,
Joachim

[Mr. P]

Rolladen werden nach dem Wert der Helligkeit draußen heruntergefahren. Wenn drinne Licht angemacht wird, dann weden die Rolladen etwas früher heruntergefahren (ggf. noch abhängig von dem Bewegungsmelder draußen )

Das ist schon mal ein guter Anfang. Hatte ich vorhin nicht bedacht (habe bislang aber auch noch keine Rollläden).
Meine Phantasie endete vorhin bei: Einschalten des Lichts, wenn ein gewisser Dämmerungswert erreicht wurde und man nach Hause kommt bzw. (und das ist schon wieder heikel wegen des WAFs) der Bewegungsmelder kombiniert mit der gemessenen Helligkeit des Raumes das Hauptlicht einschaltet.

[trilu]

Das mit den Patenten und dem Gebrauchsmusterschutz hatte ich mir auch schon mal angeschaut.
Ein Patent auf das Protokoll an sich werden sie hier in D nicht bekommen haben, sowas vergeben eigentlich nur Amerikaner.

Der Geschmacks- und Gebrauchsmusterschutz dürfte nur die Marke betreffen, also HomeMatic und oder BidCos.
Derzeit sehe ich das gelassen, es ist ja nichts durch illegale Handlungen entstanden, ich habe weder ein Device ausgelesen
noch irgendwelche, unter NDA stehende Datenblätter gelesen.

Die Lib ist rein auf Beobachtung von existierenden Devices entstanden!

[Dirk]

Hi Trilu,

Wegen dem fehlenden Wire.end() hab ich grade noch mal etwas gesucht.

Probier wirklich mal:

Code Auswählen Erweitern

TWCR = 0;
Quelle: http://forum.arduino.cc/index.php/topic,21424.0.html

Gruß
Dirk

[Prof. Dr. Peter Henning]

"Ein Gehäuse aus dem 3D-Drucker" kann jeder designen. Wenn wir Schulklassen darin unterrichten, lassen wir die Kids mit Sketchup arbeiten.

Allerdings stimme ich zu: Die Qualität ist bei den billigen Geräten nicht so, dass ich mir das ins Wohnzimmer stellen wollte.

LG

pah

[jjf]

Das mit den Patenten und dem Gebrauchsmusterschutz hatte ich mir auch schon mal angeschaut.
Ein Patent auf das Protokoll an sich werden sie hier in D nicht bekommen haben, sowas vergeben eigentlich nur Amerikaner.

Ich schliesse mal von mir auf andere:
Ein Rechtsstreit gegen eine Firma mit 1000 Mitarbeitern stehe ich/du/wir nicht durch,
auch dann nicht, wenn das Patent etc offensichtlich zu unrecht erteilt worden ist.
Den Zeit, die man dazu aufwenden muss, steht in keiner Relation zum Effekt:
meine Einschätzung: für 1% der Zeit hat man ein eigenes Protokoll entwickelt.

Im Bereich RS485 gibt es einen Sack von Protokollen, aus dem man sich was aussuchen kann
(auch ich habe da was exotisches verbrochen: Elrad 1997-08 Seite 45, Linux-Treiber für 16550 verfügbar).

Meine Empfehlung: man sollte ein weit verbreitetes Protokoll auswählen. Da wird sich was finden.

Gruss,
Joachim

[trilu]

Klar,  Protokolle gibt es genug.  Anfangs hatte ich mit der Jeelib gespielt,  aber und das war für mich entscheidend;
Ich möchte Geräte bauen die sich in eine bestehende Landschaft integrieren lassen.  Was nützt mi ein schöner Aktor,
wenn es keinen passenden Wandschalter gibt...

Ausserdem glaube ich nicht,  das eq3 daran interessiert ist,  mich zu verklagen.  Das Protokoll ist bekannt und von Anderen
Bereits in den Umlauf gebracht.  Siehe FHEM,  den CUL von busware,  usw...