Hallo zusammen,
ich hab 'nen RasPi mit ner Busware COC Karte. Das Wheezy Image kommt von Busware.
So weit so gut, alles läuft super, nur einmal am Tag gehen plötzlich alle Sensoren zur gleichen Zeit auf "dead". Mache ich nix, kommen die Sensoren nach 2 - 3 Stunden zurück. Alternative ist der Restart des FHEM Servers (nur die Applikation, nicht der ganze RasPi). Ich hab mir da schon ein Script geschrieben, dass alle 10 Minuten nachschaut und bei Bedarf ein /etc/init.d/fhem stop | start macht.
Die Sensoren senden in dieser Zeit keine Daten.
Woran kann das liegen?
Viele Grüße aus Wien
Andreas
Was fuer Sensoren?
Hi,
also das wäre mal alle :
drei Temparatursensoren HM_WDS40_TH, zwei Türkontakte HM_SEC_SC und zwei Bewegungsmelder HM_SEC_MDIR.
Danke
Andreas
Aah. Thread verschoben.
Hallo Andreas,
das dead kommt vom actionDetector - und ist auch dort zu sehen?
der actiondetector erwartet, dass sich das device zyklisch meldet - siehe Attr actCycle zur erwarteten Zeitspanne.
die Devices sollten dies automatisch tun - man kann es bei einigen steuern - siehe Register
cyclicInfoMsg
Gruss Martin
Hallo Martin,
das sieht ungefähr so aus (ActionDetector Log):
2013-12-14_09:55:01 ActionDetector status_Bewegungsmelder1: dead
2013-12-14_09:55:01 ActionDetector alive:4 dead:1 unkn:0 off:0
2013-12-14_10:05:01 ActionDetector status_Schlafzimmer: dead
2013-12-14_10:05:01 ActionDetector status_Kinderzimmer: dead
2013-12-14_10:05:01 ActionDetector status_Wohnzimmer: dead
2013-12-14_10:05:01 ActionDetector alive:1 dead:4 unkn:0 off:0
Der Status des Sensors zur selben Zeit (so sehen halt alle Sensoren zur gleichen Zeit aus):
2013-12-14_09:47:27 Kinderzimmer T: 22.5 H: 53
2013-12-14_10:05:01 Kinderzimmer Activity: dead
2013-12-14_12:05:51 Kinderzimmer temperature: 23.0
2013-12-14_12:05:51 Kinderzimmer humidity: 49
2013-12-14_12:05:51 Kinderzimmer T: 23.0 H: 49
Heute war bisher gar nix.
Ich sehe mir mal die register an.
Verstehe ich das aber richtig, dass der Action Detector selbst gar nichts auf "dead" setzt und die weitere Einlieferung von Daten damit verhindert, sondern nur den Status quasi anzeigt?
Viele Grüße aus Wien
Andreas
Hallo Andreas,
am schnellsten bekommst du die Parameter mit
define hm HMinfo
set hm param -d actStatus actCycle R-cyclicInfoMsg autoReadReg
list ActionDetector
Gruss Martin
Hallo Andreas, Martin,
ich beobachte seit kurzem bei mir das gleiche Verhalten. Exakt zum gleichen Zeitpunkt "verschwinden" meine drei RTs, vom ActionDetector werden sie als dead gemeldet. Einige Zeit später (Minuten/Stunden) erscheinen alle zum gleichen Zeitpunkt wieder.
Heute z.B.:
2013-12-16_13:45:27 ActionDetector alive:3 dead:0 unkn:0 off:0
2013-12-17_23:15:32 ActionDetector status_dg_Thermostat: dead
2013-12-17_23:15:32 ActionDetector status_az_Thermostat: dead
2013-12-17_23:15:32 ActionDetector status_wz_Thermostat: dead
2013-12-17_23:15:32 ActionDetector alive:0 dead:3 unkn:0 off:0
2013-12-17_23:45:33 ActionDetector status_dg_Thermostat: alive
2013-12-17_23:45:33 ActionDetector status_az_Thermostat: alive
2013-12-17_23:45:33 ActionDetector status_wz_Thermostat: alive
2013-12-17_23:45:33 ActionDetector alive:3 dead:0 unkn:0 off:0
2013-12-18_06:55:34 ActionDetector status_dg_Thermostat: dead
2013-12-18_06:55:34 ActionDetector status_az_Thermostat: dead
2013-12-18_06:55:34 ActionDetector status_wz_Thermostat: dead
2013-12-18_06:55:34 ActionDetector alive:0 dead:3 unkn:0 off:0
2013-12-18_12:05:35 ActionDetector status_dg_Thermostat: alive
2013-12-18_12:05:35 ActionDetector status_az_Thermostat: alive
2013-12-18_12:05:35 ActionDetector status_wz_Thermostat: alive
2013-12-18_12:05:35 ActionDetector alive:3 dead:0 unkn:0 off:0
Bei mir läuft FHEM auf der FB7390 - die HM Devices werden alle von einem CUL angesteuert.
Hier die Parameter:
set hm param -d actStatus actCycle R-cyclicInfoMsg autoReadReg
param done:
param list
entity : actStatus |actCycle |R-cyclicInfoMsg |autoReadReg |
az_Thermostat : alive |000:10 |on |4_reqStatus
az_podFS1010 : - | - | - |4_reqStatus
dg_Thermostat : alive |000:10 |on |4_reqStatus
ke_Pumpe : - | - | - |4_reqStatus
ke_Switch4 : - | - | - |4_reqStatus
ku_Switch1 : - | - | - |4_reqStatus
wz_Markise : - | - | - |4_reqStatus
wz_Thermostat : alive |000:10 |on |4_reqStatus
list ActionDetector
Internals:
CHANGED
DEF 000000
IODev CUL_HM
NAME ActionDetector
NR 89
STATE alive:3 dead:0 unkn:0 off:0
TYPE CUL_HM
Readings:
2013-12-18 23:45:36 state alive:3 dead:0 unkn:0 off:0
2013-12-18 23:45:36 status_az_Thermostat alive
2013-12-18 23:45:36 status_dg_Thermostat alive
2013-12-18 23:45:36 status_wz_Thermostat alive
Helper:
actCycle 600
peers 21DC30,21DE95,21F220
rxType 1
21dc30:
recent 2013-12-18 23:45:13
start 2013-12-16 13:35:27
21de95:
recent 2013-12-18 23:44:49
start 2013-12-16 13:35:26
21f220:
recent 2013-12-18 23:45:20
start 2013-12-16 13:35:27
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
vrt 1
Shadowreg:
Attributes:
actCycle 600
event-on-change-reading .*
room Unsorted
In den übrigen Logs finde ich keinerlei Anhaltspunkte oder Einträge, die zu den Zeitpunkten "Verschwinden" bzw. "Wiederauftauchen" passen würden.
Ratlos,
Tobias
Hi Thomas,
der ActionDetector selbst prüft regelmäßig den Zustand der angemeldeten Devices. Die Periode ist attribut
ActionDetector -> actCycle
festgelegt - default ist 600 = 10 min.
Daher kommen alle Meldungen gleichzeitig.
Die eigentliche Prüfung ist, dass der Delinquent sich in der vereinbarten Periode gemeldet haben muss - irgend etwas sollte FHEM von ihm empfangen haben.
Die erlaubte Periode steht in Device
attr <dev> actCycle ...
bei deinen Devices ist es 10 min
Da es sich im Thermostate handelt sollten sich diese alle 2,5 min melden - also 3-4 mal in 10 min.
ActionDetector behauptet nun, dass
17ter 23:15:32 dg_Thermostat: dead
17ter 23:45:33 dg_Thermostat: alive
==> von 17ter 23:05 bis mindestens 23:35 keine Meldung des Thermostat
18ter 06:55:34 dg_Thermostat: dead
18ter 12:05:35 dg_Thermostat: alive
==> von 18ter 06:45 bis mindestens 11:55 keine Meldung des Thermostat
loggst du die temperaturen? Dann kannst du dies im Logfile prüfen.
Kannst du es nachvollsiehen? Oder stimmt etwas nicht?
Gruss Martin
Hallo Martin,
danke für die Erklärungen - soweit alles verstanden. Ich logge die Temperaturen meiner drei RT Thermostate ganz normal jeweils in einem eigenen Logfile. Die Logfiles weisen für den "dead"-Zeitraum keine Einträge auf.
Am Beispiel des dg_Thermostat - bei den beiden anderen Thermostate sehen die Logs analog aus:
2013-12-18_06:36:51 dg_Thermostat desired-temp: 17
2013-12-18_06:36:51 dg_Thermostat actuator: 0 %
2013-12-18_06:39:10 dg_Thermostat measured-temp: 18.4
2013-12-18_06:39:10 dg_Thermostat desired-temp: 17
2013-12-18_06:39:10 dg_Thermostat actuator: 0 %
2013-12-18_06:41:14 dg_Thermostat measured-temp: 18.3
2013-12-18_06:41:14 dg_Thermostat desired-temp: 17
2013-12-18_06:41:14 dg_Thermostat actuator: 0 %
2013-12-18_06:44:07 dg_Thermostat measured-temp: 18.2
2013-12-18_06:44:07 dg_Thermostat desired-temp: 17
2013-12-18_06:44:07 dg_Thermostat actuator: 0 %
2013-12-18_06:55:33 dg_Thermostat Activity: dead
2013-12-18_12:02:59 dg_Thermostat measured-temp: 22.8
2013-12-18_12:02:59 dg_Thermostat desired-temp: 21
2013-12-18_12:02:59 dg_Thermostat actuator: 12 %
2013-12-18_12:05:35 dg_Thermostat Activity: alive
2013-12-18_12:05:58 dg_Thermostat measured-temp: 22.8
2013-12-18_12:05:58 dg_Thermostat desired-temp: 21
2013-12-18_12:05:58 dg_Thermostat actuator: 12 %
Was ich nicht verstehe - drei unabhängige (insbesondere keine Peers) Thermostate können ja nicht gleichzeitig das Senden aufhören und wieder beginnen. Batterie- und Empfangsprobleme schliesse ich somit aus. Die RSSI-Werte für die Thermostate sind gut (avg besser -55).
Insofern müsste das Problem somit eher auf der Empfangsseite (beim FHEM-Server) liegen. Da Andreas das gleiche Verhalten auf einem RPi mit CoC sieht, ist es unwahrscheinlich, dass es bei mir an der Kombination FB7390 und CUL liegt. Die CPU-Auslastung der FB7390 ist ganz normal. Der FHEM-Server friert aber auch nicht komplett ein - die Erfassung der 1wire Temperaturwerte der Heizung (via ECMD - ok, das ist "pull") z.B. ist lückenlos.
Und ist http://forum.fhem.de/index.php/topic,17622.0.html (http://forum.fhem.de/index.php/topic,17622.0.html) evtl. "related" ?
Lässt sich das durch Erhöhen von LogLevels eingrenzen? Wenn ja wie und für welche Komponenten? Dummerweise tritt das Problem ja nur sporadisch auf.
Danke (wie immer) für deine Mühe
Gruss
Tobias
Hallo Tobias,
das gute ist also , dass der ActionDetector korrekt arbeitet - und auch Probleme aufdeckt.
Es stellt sich die Frage, warum nichts mehr ankommt. SW-Problem ist bei SW immer möglich :(
Könnte auch am IO-device liegen.
Kommt zur Gegebenen Zeit irgend-etwas an? Es sind ja immer hin 5 Stunden. Ich betreibe neben den Logs für Graphen nur ein generelles Logfile - falls du so etwas hast kannt du nachsehen, ob irgend etwas passiert ist.
define log_all FileLog log/all_%Y.log .*
attr log_all logtype text
besser in diesem Fall ist das loggen der messages - kannst du hier selektiv machen:
Da du eine CUL hast geht es nicht selektiv - also:
attr global verbose 1
attr global mseclog 1
attr <CUL> verbose 5
Gruss Martin
Bei lief es jetzt mal drei Tage einwandfrei durch.
Gestern wieder alles zum gleichen Zeitpunkt auf "dead". Meine RSSI Werte liegen eigentlich immer < 80 auf allen Sensoren.
Es sind aber auch Sensoren betroffen, die direkt neben dem FHEM server liegen (Temparatur + Bewegungsmelder). Da ich bei mir auch das CCD von Busware einsetze, bin ich über diesen beitrag gestolpert:
http://forum.fhem.de/index.php/topic,15128.msg97877.html#msg97877
Hab irgendwie das Gefühl, dass es bei mir auch bei erhöhter Aktivität aussetzt.
Werde mal das Flashen der Firmware probieren, wobei mein CCD erst 2 Wochen alt ist..
Hallo Andreas, Martin,
Zitat von: martinp876 am 19 Dezember 2013, 13:22:19
Kommt zur Gegebenen Zeit irgend-etwas an? ...
Zumindest während einer "dead"-Zeitspanne des Thermostats hat FHEM einmal erfolgreich via Homematic die Heizungspumpe eingeschaltet:
2013-12-06_04:36:12 ActionDetector status_wz_Thermostat: dead
2013-12-06_04:36:12 ActionDetector alive:0 dead:1 unkn:0 off:0
2013-12-06_05:36:12 ActionDetector status_wz_Thermostat: alive
2013-12-06_05:30:00 ke_Pumpe set_on
2013-12-06_05:30:01 ke_Pumpe level: 100 %
2013-12-06_05:30:01 ke_Pumpe pct: 100
2013-12-06_05:30:01 ke_Pumpe deviceMsg: on (to CUL_HM)
2013-12-06_05:30:01 ke_Pumpe on
2013-12-06_05:30:01 ke_Pumpe timedOn: off
Vielleicht hat aber in diesem Fall gerade der Sende-Befehl von FHEM an die Pumpe und deren Antwort auch den Empfang von den Thermostaten wieder in Gang gebracht??
In meiner Umgebung sehe ich aber auch nicht wirklich erhöhte Aktivität als Fehlerquelle. Es sind derzeit gerade einmal 3 RTs, die kontinuierlich senden. Die sporadischen "dead"-Zeiträume sehe ich im Log des Action Detectors aber auch schon, als ich gerade mal nur ein einziges Thermostat aktiv hatte.
Falls das weiterhin öfter passiert (seit drei Tagen läuft es gerade ohne Probleme - toi toi toi), werde ich es mal mit dem von Martin vorgeschlagenen erweiterten Logging versuchen.
Gruß
Tobias
Bei mir war es gerade wieder weg.
hab aber auch dran rumgebastelt, und zwar wollte ich mir mal mit "screen" das Device anzeigen lassen. Ab dem Moment war schluss und die Devices sind der Reihe nach auf dead gegangen.
War das in dem Falle mein Fehler?? Oder war's Zufall?
@thomas
interessante Theorie, dass der receiver des HMLAN einschläft und durch ein Senden aufgeweckt wird.
@andreas
welches screen?
kann es sein, dass dann das HMLAN ein problem hatte? Überlast? Bitte details,was screen macht/machen solll
Gruss Martin
ich wollte mal mit "screen /dev/ttyAMA0" auf das device schauen.
Ich dachte, da bekomm ich die aktuelle Firmware für's flashen raus.
ich wollte mir mal ansehen, was bei:
screen /dev/ttyAMA0
Da war dann sofort Schluss. Alle Sensoren auf "dead".
Ich habe jetzt mal das Logging voll aufgedreht. Da kommt sowas bei raus:
2013.12.20 23:16:01.861 5: CUL/RAW: /A0C73867
2013.12.20 23:16:01.884 5: CUL/RAW: A0C73867/023992F00000000DC320B
2013.12.20 23:16:01.885 5: CCD: A0C73867023992F00000000DC32 -68.5
2013.12.20 23:16:01.886 5: CCD dispatch A0C73867023992F00000000DC32::-68.5:CCD
2013.12.20 23:16:25.677 5: CUL/RAW: /A0C91867
2013.12.20 23:16:25.700 5: CUL/RAW: A0C91867/0239BF700000000EF2C59
2013.12.20 23:16:25.702 5: CCD: A0C918670239BF700000000EF2C -29.5
2013.12.20 23:16:25.703 5: CCD dispatch A0C918670239BF700000000EF2C::-29.5:CCD
2013.12.20 23:17:12.175 5: CUL/RAW: /A0DD8A64
2013.12.20 23:17:12.198 5: CUL/RAW: A0DD8A64/11F7DE8F112340141248050
2013.12.20 23:17:12.199 5: CCD: A0DD8A6411F7DE8F1123401412480 -34
2013.12.20 23:17:12.200 5: CCD dispatch A0DD8A6411F7DE8F1123401412480::-34:CCD
2013.12.20 23:17:12.208 5: CCD sending As0DD88002F112341F7DE801012400
2013.12.20 23:17:12.299 5: SW: As0DD88002F112341F7DE801012400
2013.12.20 23:17:12.313 5: CCD sending As0DD88002F112341F7DE80101C800
2013.12.20 23:17:12.482 5: SW: As0DD88002F112341F7DE80101C800
Im Moment läuft wieder alles.
Mal sehen, wie lange. Dann melde ich mich nochmal
Hallo Andreas74,
ich hatte ein ähnliches Problem mit einem HM-CFG-LAN und einem HM-CC-RT-DN.
Beide "unterhielten" sich eine ganze Weile problemlos bevor das Thermostat sich weder steuern noch abfragen liess.
Erst als ich fhem beendet hatte und die beiden Komponenten mit der HomeMatic Software "zusammengebracht" hatte, lief das Ganze auch unter fhem problemlos- seither ohne jegliche Störungen.
Vielleicht war es bei mir auch wirklich nur ein Zufall...
Gruß,
Roland
Hallo,
ich beobachte (vermutlich) das gleiche.
Mein Setup ist ein Raspberry Pi, busware COC + 4 homematic temperaturregel + 2 HM schaltsteckdosen + 2 HM schalter.
In den letzten Tagen habe ich mittlerweile 3 mal beobachtet, wie das loggen der Daten in die MySQL DB stehen blieb und nach 2 bis 6 Stunden wieder eingesetzt hat.
In den log-files finde ich zu diesen Zeitpunkten ein:
--- SNIP---
2013-12-23_15:23:06 1OG_Kinderschlafzimmer T: 20.5 H: 56
2013-12-23_15:23:06 1OG_Kinderschlafzimmer measured-temp: 20.5
2013-12-23_15:23:06 1OG_Kinderschlafzimmer humidity: 56
2013-12-23_15:39:48 1OG_Kinderschlafzimmer Activity:: dead
2013-12-23_17:01:38 1OG_Kinderschlafzimmer Activity:: dead
2013-12-23_17:02:04 1OG_Kinderschlafzimmer T: 20.6 H: 57
2013-12-23_17:02:04 1OG_Kinderschlafzimmer measured-temp: 20.6
2013-12-23_17:02:04 1OG_Kinderschlafzimmer humidity: 57
---SNAP---
Als ich mit munin den Raspi in mein monitoring eingebunden habe, habe ich zum Zeitpunkt des Ausfall ein vollständiges absacken der aktivität auf dem uart-pl011 interrupt beobachtet.
Grüße
hj
hi hj
es sind also keinerlei events mehr gekommen? Der HMLAN war operationell, keine Fehler? Was war das letzte reading überhaupt?
vermutest du ein Problem deiner Platform?
Gruss Martin
So da war es wieder:
"all_log" Verbose 5
2013.12.24 16:31:29.531 5: CUL/RAW: /A0CB0867
2013.12.24 16:31:29.554 5: CUL/RAW: A0CB0867/0239B2F00000000E6333F
2013.12.24 16:31:29.555 5: CCD: A0CB08670239B2F00000000E633 -42.5
2013.12.24 16:31:29.556 5: CCD dispatch A0CB08670239B2F00000000E633::-42.5:CCD
2013.12.24 16:32:10.626 5: CUL/RAW: /A0CDA867
2013.12.24 16:32:10.649 5: CUL/RAW: A0CDA867/0239BF700000000F02F58
2013.12.24 16:32:10.650 5: CCD: A0CDA8670239BF700000000F02F -30
2013.12.24 16:32:10.651 5: CCD dispatch A0CDA8670239BF700000000F02F::-30:CCD
2013.12.24 16:33:35.937 5: CUL/RAW: /A0CBA867
2013.12.24 16:33:35.961 5: CUL/RAW: A0CBA867/023992F00000000DF3314
2013.12.24 16:33:35.962 5: CCD: A0CBA867023992F00000000DF33 -64
2013.12.24 16:33:35.963 5: CCD dispatch A0CBA867023992F00000000DF33::-64:CCD
2013.12.24 16:33:48.602 5: CUL/RAW: /A0D30A64
2013.12.24 16:33:48.625 5: CUL/RAW: A0D30A64/11F7DE8F11234017A28804D
2013.12.24 16:33:48.626 5: CCD: A0D30A6411F7DE8F11234017A2880 -35.5
2013.12.24 16:33:48.628 5: CCD dispatch A0D30A6411F7DE8F11234017A2880::-35.5:CCD
2013.12.24 16:33:48.635 5: CCD sending As0D308002F112341F7DE801012800
2013.12.24 16:33:48.726 5: SW: As0D308002F112341F7DE801012800
2013.12.24 16:33:48.740 5: CCD sending As0D308002F112341F7DE80101C800
2013.12.24 16:33:48.909 5: SW: As0D308002F112341F7DE80101C800
2013.12.24 16:52:03.553 0: Server shutdown
Einer der Sensoren:
2013-12-24_16:31:29 Kinderzimmer temperature: 23.0
2013-12-24_16:31:29 Kinderzimmer humidity: 51
2013-12-24_16:31:29 Kinderzimmer T: 23.0 H: 51
2013-12-24_16:49:14 Kinderzimmer Activity: dead
2013-12-24_16:52:26 Kinderzimmer Activity: dead
2013-12-24_16:54:14 Kinderzimmer temperature: 23.0
Das ActionDetector Log
2013-12-24_16:49:14 ActionDetector status_Bewegungsmelder1: dead
2013-12-24_16:49:14 ActionDetector status_Schlafzimmer: dead
2013-12-24_16:49:14 ActionDetector status_Kinderzimmer: dead
2013-12-24_16:49:14 ActionDetector status_Wohnzimmer: dead
2013-12-24_16:49:14 ActionDetector alive:1 dead:4 unkn:0 off:0
2013-12-24_16:52:26 ActionDetector alive:0 dead:1 unkn:0 off:0
2013-12-24_16:52:26 ActionDetector status_Eingangstuer: alive
2013-12-24_16:52:26 ActionDetector alive:1 dead:1 unkn:0 off:0
2013-12-24_16:52:26 ActionDetector status_Kinderzimmer: dead
2013-12-24_16:52:26 ActionDetector alive:1 dead:2 unkn:0 off:0
2013-12-24_16:52:26 ActionDetector status_Schlafzimmer: dead
2013-12-24_16:52:26 ActionDetector alive:1 dead:3 unkn:0 off:0
2013-12-24_16:52:26 ActionDetector status_Wohnzimmer: alive
2013-12-24_16:52:26 ActionDetector alive:2 dead:3 unkn:0 off:0
2013-12-24_17:02:26 ActionDetector status_Bewegungsmelder1: alive
2013-12-24_17:02:26 ActionDetector status_Schlafzimmer: alive
2013-12-24_17:02:26 ActionDetector status_Kinderzimmer: alive
2013-12-24_17:02:26 ActionDetector alive:5 dead:0 unkn:0 off:0
Um 16:52 wurde fhem automatisch neu gestartet. Nach 10 Minuten waren alle Devices wieder "online".
Es war keine besondere Aktivität. Ich hatte irgendwelche Mikrowellen, dect - geschichten hier in der Wohnung im Verdacht. Auch hatte ich noch eine alte Aldi Wetterstation hier am Laufen. Zum fraglichen Zeitpunkt war alles abgeschaltet. Im Schnitt aller zwei bis drei Tage passiert die gleiche Geschichte. Alle Sensoren gehen auf dead.
Ein Restart des FHEM Servers behebt das ganze.
Nur so ne Idee:
kann es sein, dass noch irgendetwas anderes auf das CC1101 Device zugreift und damit die Einlieferung von Daten und den "alive" Meldungen sperrt?
Oder zu viele IP Ports, die nicht mehr geschlossen werden??
Hallo Andreas,
wie die Logs zeigen empfängt FHEM nichts vom Kinderzimmer zwischen 16:33 und 16:52. Der ActionDetector ist also korrekt.
Offensichtlich wurde garnichts mehr empfangen.
Wenn ich dich richtig verstehe wurde das Problem mit einen neustart behobem
Das Problem liegt demnach im Bereich CUNO (dein Device?) und der Kommunikation. Ist schwer zu sagen, was nicht funktioniert, CUNO oder FHEM. HMLAN hat hier einen watchdog laufen, der eine Unterbrechung der Kommunikation erkennt und versucht HMLAN/USB ggf neu zu starten. Bei CUL/CUN gibt es so etwas nicht.... ich werden einmal bei Rudi anfragen. m.E. macht dies absolut sinn
Du hast CUL oder CUNO?
Gruss Martin
Hi,
und schöne Feiertage erstmal ;-)
ich hab das Busware CCD incl. RPi (http://shop.busware.de/product_info.php/products_id/94?osCsid=a0d7e0c6a07d9c3b75e3b4ce64a106ef) mit der 5 dbi / 15 cm Antenne.
Alles Original mit dem Busware Image. Heute ist's mir zwei mal passiert :-(.
Ich werd mal ein anderes Netzteil dran machen, obwohl auch das original Busware ist.
Mal sehen ...
Ich geb's auf.
Ich halte das ganze höchstens 1,5 Tage oben.
Ich trage mich jetzt schweren Herzens mit dem Gedanken, das ganze auf eine HMLan Lösung mit dem RPi umzuziehen.
Ich hätte dann zwar richtig Lehrgeld bezahlt, aber ich bekomme den Busware CCD einfach nicht stabil in's Laufen.
Kann HMLan eigentlich den CCD ersetzen, sprich kann ich über HMLan und FHEM alles so steuern, wie mit dem CCD?
Viele grüße
Andreas
Hi Andreas,
ich bin mir sicher, dass CUNO2 aktuell zu langsam ist, um HM zu unterstützen. CUL funktioniert prima.
Wenn ich davon ausgehen, dass CCD einer CUNO ähnelt (kann man sicher irgendwo recherchieren) dann hat diese evtl das gleiche Problem im Bezug auf delay und Ethernet.
Kolplett 'tot' ist eine CUNO allerdings nie gewesen - nur zu langsam.
Ein HMLAN kann für Homematic alles bedienen, was ich kenne. Sonst aber nichts. HM Produkte sind intelligenter als CUL/CUNO - was vor und Nachteile haben kann, besonders wenn man die Spec der Intelligenz nicht hat.
Was eine CCD sonst noch kann... was ist Alles?
Gruss Martin
Hi Martin,
also ich möchte eigentlich nur in 4 Zimmern Temparatur/Luftfeuchtigkeit, an einer Eingangstür Close/Open, und an zwei bewegungsmeldern "Motion" erkennen und auf all das reagieren (Bash Scripten / smsServerTools / FHEM Logik).
Also SMS,wenn Tür offen und Axis Kamera an, wenn Bewegung + Tür offen. Evtl noch zwei oder drei Schaltsteckdosen und einen oder zwei Funktaster um Licht aus / an oder Webradio aus/an (SWR3, hier im Ausland ein echtes Glücksgefühl mal ab und an die Staumeldungen auf der A5 und A8 hören zu können ;-)).
Ich würde komplett bei Homematic bleiben. Die komplette Logik bezüglich SMS und Axis Kamera hab ich schon mit Scripten und FHEM abgebildet.
Das klappt ja alles wunderbar. Ich hätte es halt gern in "stabil".
HMLAN macht die Kommunikation zu HM devices - alles andere musst du wo anders machen.
FHEM ist modular - ein austausch des IO devices sollte kein wirkliches Problem sein
ZitatWenn ich davon ausgehen, dass CCD einer CUNO ähnelt
Ich habe das CCD noch nie live gesehen, aber der verwendet kein Ethernet bzw. TCP/IP sondern die serielle Leitung, u die Daten an FHEM zu uebertragen. Das bedeutet, dass die beiden wohl ganz unterschiedliche Probleme haben werden :)
Verstehe ich das richtig:
Alle Devices werden mit HMLan über die Windows Software einmalig zusammen gebracht. Danach "reden" die Devices mit HMLan und FHEM macht die Logik dahinter und liest die Werte wie temparatur, Tür offen / zu, "Motion" usw. vom HMLan aus und arbeitet damit?
Das einzige, was ich dann anders basteln müsste, wäre der IR Receiver. Den hat der CCD an Board.
Ich glaube allmählich, dass der CCD einfach zu viel Strom zieht. Dabei hab ich schon ein 5 V / 2000 mA Netzteil dran.
Hallo Andreas,
nein- falsch. HMLAN ist erst einmal ein IO device wie CUL/CUNO/CCD.
HMLAN ist aber nicht ganz so 'transparent' wie die busware devices. So sendet HMLAN selbständig ACKs und wiederholt messages. Das alles ist in FW realisiert und somit sehr schnell. Ausserdem handelt es AES. Dies setzt voraus, dass HMLAN mit den entsprechenden Daten versorgt wird.
Aber ansonsten ist HMLAN transparent.
Für dich als User ist dies transparent - du wirst/sollst keinen Unterschied zwischen den IOs sehen.