Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Dirk · 19 April 2014, 21:51:30

Wo soll ich das denn "hinchecken"?
Contrib wird ja wohl nicht automatisch aktualisiert.
Allerdings braucht THPL ja auch nicht jeder?

hexenmeister · 19 April 2014, 22:07:32

ZitatAllerdings braucht THPL ja auch nicht jeder?

Na dann 'ne Frage an die FHEM-Perl-Profis: Wie macht man so, dass diese Datei nur dann geladen wird, wenn ein entsprechendes Device auch wirklich exisitiert (angemeldet wurde)?

Dirk · 19 April 2014, 22:13:08

Das haben wir weiter unten schon mal diskutiert.
So ähnlich macht es das wohl das Firmata-Modul. Kurz gesagt, der Umbau das das CUL_HM so macht ist nicht unerheblich. Daher gibt es kurzfristig diesen Weg, dass alle Dateien geladen die mit "HMConfig_" beginnen.

Dirk · 19 April 2014, 22:21:04

Ich habe mich noch mal mit den Außensensor und der Lichtempfindlichkeit und eventueller Filter beschäftigt.

mein aktueller Plan ist Fensterfilterfolie zu bverwenden. Diese hat eine definierte Lichtdurchlässigkeit und das Ganze reproduzierbar machen. Erste Tests waren auch ganz vielversprechend.
Die Folie die ich hier habe, lässt laut Beschreibung nur ca. 26% Licht durch. Ersten Tests heute Nachmittag, leider ohne direkte Sonne, scheinen das auch zu bestätigen. Verglichen habe ich das mit einem zweiten Sensor ohne Abdeckung.
Der Einbau der Folie ist so auch recht einfach. Ich werde die nächsten Tage mal eine Messreihe machen.

Gruß
Dirk

hexenmeister · 19 April 2014, 22:48:03

ZitatKurz gesagt, der Umbau das das CUL_HM so macht ist nicht unerheblich.

Hm... Ist mir beim schnellen Durchlesen entgangen.

OK, ich halte trotzdem ein Einchecken in den FHEM-Zweig für tragbar. Auch wenn die wenigsten FHEM-Nutzer das Device haben werden, ein nennenswertes Overhead wird dadurch ja auch nicht generiert.

betateilchen · 19 April 2014, 22:53:48

Zitat von: Dirk am 19 April 2014, 21:51:30
Wo soll ich das denn "hinchecken"?
Allerdings braucht THPL ja auch nicht jeder?

Na, nach FHEM - wohin sonst?

Du willst doch nicht allen Ernstes behaupten, dass dort nur Dateien eingecheckt sind, die JEDER braucht

Wenn es danach ginge, könnte man mindestens 70% aller Module in FHEM nach contrib verschieben.

Thorsten Pferdekaemper · 23 April 2014, 22:49:39

Mal was ganz anderes: Ist eigentlich das Peeren schon richtig implementiert? Ich hab's mal ausprobiert, also...

Code Auswählen

set DirksSensor peerChan 0 og_bd_Heizung_Weather
Im List vom og_bd_Heizung_Weather sieht das dann so aus:

Code Auswählen

  device     og_bd_Heizung
   peerList   DirksSensor,DirksSensor_chn:02,
   Readings:
     2014-04-23 22:03:12   R-sign          off 
     2014-04-23 22:36:18   measured-temp   16.4
     2014-04-23 22:03:12   peerList        DirksSensor,DirksSensor_chn:02,
     2014-04-23 22:36:18   state           16.4
   Helper:
     peerIDsRaw ,6FB75E02,6FB75E01,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   expert     1
   group      og_Bad
   model      HM-CC-RT-DN
   peerIDs    00000000,6FB75E01,6FB75E02,

Im list zum Sensor kann ich allerdings dazu nichts sehen. Ich habe auch ein getConfig versucht, aber das scheint ewig auf CMD_pending hängen zu bleiben.
Ich dachte zuerst, dass es gar nicht funktionieren würde, als ich aber den Sensor in den Kühlschrank gelegt habe, hat der RT im Bad geglaubt, das Fenster wäre offen. Ich habe den Eindruck, dass die Übernahme der Werte verzögert bzw. manchmal gar nicht erfolgt. Hier ist ein Auszug aus einem FileLog, das die Werte von beiden zeigt:

Code Auswählen

2014-04-23_22:08:21 DirksSensor T: 22.3 H: 57 Lux: 0.06 P: 1007 batVoltage: 2.38
2014-04-23_22:08:35 og_bd_HeizungOp T: 22.3 desired: 18.0 valve: 0
2014-04-23_22:10:46 DirksSensor T: 21.9 H: 50 Lux: 0 P: 1007 batVoltage: 2.36
2014-04-23_22:10:57 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:12:56 DirksSensor T: 21.4 H: 48 Lux: 0 P: 1007 batVoltage: 2.36
2014-04-23_22:13:05 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:15:57 DirksSensor T: 21.1 H: 49 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:16:02 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:18:43 DirksSensor T: 19.7 H: 38 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:18:44 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:21:13 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:21:14 DirksSensor T: 16.0 H: 34 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:23:26 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:23:31 DirksSensor T: 14.3 H: 32 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:26:29 og_bd_HeizungOp T: 22.3 desired: 18.0 valve: 0
2014-04-23_22:26:37 DirksSensor T: 16.4 H: 82 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:29:18 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:29:29 DirksSensor T: 18.5 H: 76 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:31:53 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:32:07 DirksSensor T: 19.6 H: 72 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:34:13 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:34:30 DirksSensor T: 20.2 H: 72 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:36:18 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:36:38 DirksSensor T: 20.5 H: 70 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:39:14 og_bd_HeizungOp T: 20.5 desired: 12.0 valve: 0
2014-04-23_22:39:37 DirksSensor T: 20.8 H: 69 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:41:54 og_bd_HeizungOp T: 20.5 desired: 12.0 valve: 0
2014-04-23_22:42:21 DirksSensor T: 21.0 H: 69 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:44:21 og_bd_HeizungOp T: 20.5 desired: 18.0 valve: 0
2014-04-23_22:44:51 DirksSensor T: 21.1 H: 69 Lux: 0 P: 1007 batVoltage: 2.38

Kann es sein, dass da das Timing der Kommunikation noch nicht so ganz stimmt?
Gruß,
Thorsten

Dirk · 23 April 2014, 23:40:52

Zitat von: Thorsten Pferdekaemper am 23 April 2014, 22:49:39
Kann es sein, dass da das Timing der Kommunikation noch nicht so ganz stimmt?

Das könnte gut sein.

Das Peering habe ich tatsächlich aktuell etwas vernachlässigt, ich habe leider keinen HM-CC-RT-DN zum testen.
Es gibt noch ein 1-2 Stellen im Code der mit delay's arbeitet. Vor allen beim Lesen des Helligkeitssensors. Ja ich weiß das soll man nicht machen. Das war aber ein schneller Weg den Sensor zu laufen zu bringen. Hier kommen mit Sicherheit noch einige Timings durcheinander. Und ich kann mir vorstellen dass da der Sensor den Timeslot bei dem der RT auf Empfang ist ab und zu verpasst.

Das werde ich die nächsten Tage noch ändern.

Update:
Du benutzt aber das "normale" Hex-File, also nicht das was alle 10 Sek. sendet?

Thorsten Pferdekaemper · 24 April 2014, 08:39:58

Zitat von: Dirk am 23 April 2014, 23:40:52Das Peering habe ich tatsächlich aktuell etwas vernachlässigt, ich habe leider keinen HM-CC-RT-DN zum testen.

Das kann ich dann erledigen.

Zitat
Es gibt noch ein 1-2 Stellen im Code der mit delay's arbeitet.

Böse, böse...

ZitatDas werde ich die nächsten Tage noch ändern.

Ok, Du scheinst zu wissen, wo Du hinfassen musst, dann lasse ich die Finger davon.

Zitat
Update:
Du benutzt aber das "normale" Hex-File, also nicht das was alle 10 Sek. sendet?

Ja, das normale. Im FileLog-Ausschnitt aus meinem vorherigen Post kannst Du das Timing sehen.

Hast Du auch eine Idee, wo das "CMDs_pending" herkommt? Das Teil scheint gar keine Kommandos zu verarbeiten. Beim peering bleibt es auf "2 CMDs_pending" hängen, ebenso beim getConfig.

Gruß,
Thorsten

santalaus · 25 April 2014, 14:40:03

Hallo,

kurze Status Meldung:
Die Bewegungsmelder liegen beim Zoll, da keine Zoll Unterlagen oder Rechnung drauf war.
Ich bin gespannt ob ich die Mitnehmen darf!

z.Z: Suche ich alle Unterlagen zusammen ist aber umständlich, da ich eingeschränkt bin.
Vor 2 Tagen ist der Blitz direkt ins Nachbarhaus. Da gibt es z.Z. andere Prioritäten.

Nico

hexenmeister · 25 April 2014, 15:24:14

Ich musste auch schon paar mal zum Zoll.
Die Sachen wirst Du mitnehmen können. Nimm die Rechnung mit, bzw. die Zahlungsbestätigung, eBay-Ausdruck etc.
Ich habe auch bereits zwei kleine Bewegungsmelderplatinchen liegen. Ich bastele dann mit

Dirk · 03 Mai 2014, 00:15:00

Hallo,

es gibt ein kleines Update im Github.

Das Flash-Tool gibt es dort nun auch für den Raspberry Pi.
Man kann das Firmware-Update nun auch über die GPIO-Pins des Raspberry Pi durchführen.
Dazu ist dann kein USB-Serialadapter erforderlich.

Gruß
Dirk

Thorsten Pferdekaemper · 03 Mai 2014, 01:31:39

Hi,
Hattest Du auch schon Gelegenheit, Dir das Peering anzuschauen?
Gruß,
Thorsten

Dirk · 05 Mai 2014, 20:05:05

Hallo Thorsten,

Mit dem Peering habe ich mich noch nicht beschäftigt.
Ich brauche hier vermutlich auch Unterstützung, da ich keine passende Partner zum Peeren habe.

Ich habe je die noch immer eingebauten Sleeps in Verdacht.

Soll ich dir mal eine Firmwareversion schicken wo das Auslesen des Helligkeitssensors abgeschaltet ist, oder kannst du das mal testen?

Gruß
Dirk

trilu · 05 Mai 2014, 20:23:02

Hallo Zusammen,
Peering sollte eigentlich funktionieren. In der bisherigen Konfiguration sende ich auch nur Temperatur und Luftfeuchtigkeit. Ich habe mich an die Vorgaben des Dummy Devices von Martin gehalten.
Vom Timing bin ich mir nicht ganz sicher ob es stimmt. Die Wartezeit bis zur nächsten Übermittlung wird ja auf Basis des Messagezählers errechnet. Derzeit nutze ich den Aktuellen, kann aber sein das man den Nächsten nehmen muss. Eigentlich macht das keinen grossen Unterschied. Nur wenn der Messagezähler auf 0 ist, dann ist der aktuelle ja 255 und dann macht es eine Unterschied...
Testet mal ohne die Sleeps, wenn es das nicht war, dann gehen wir das Thema Messagezähler an.
Viele Grüsse
Horst