Alternative culfw

RaspiLED · 19 Februar 2017, 20:35:04

Hi Andreas,

Danke für die Hinweise! Dann brauchen wir die Leiden eines Windows Ordner auf Samba Freigaben ja nicht wiederholen!

Gruß us Kölle,
Arnd

Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...

A.Harrenberg · 19 Februar 2017, 20:37:40

Hi RaspiLED,

interessanterweise funktioniert ein anderes Repository von GIT im gleichen Verzeichnis von Windows aus einwandfrei. Aber ich habe jetzt nicht den Nerv das weiter zu verfolgen und die Ursache zu finden.

Gruß,
Andreas.

Master_Nick · 21 Februar 2017, 13:47:57

Bjoern muss man für den Empfang des Maverick Grillthermometers (733er Frequenz) noch was in die a-culfw bringen?

Hatte das hier dazu gefunden: https://forum.fhem.de/index.php/topic,51128.msg565659.html#msg565659

Da heißt es, es wurde als Idee geäußert es in die CulFW zu bringen.

bjoernh · 21 Februar 2017, 14:14:22

Zitat von: Master_Nick am 21 Februar 2017, 13:47:57
Bjoern muss man für den Empfang des Maverick Grillthermometers (733er Frequenz) noch was in die a-culfw bringen?

Hatte das hier dazu gefunden: https://forum.fhem.de/index.php/topic,51128.msg565659.html#msg565659

Da heißt es, es wurde in die CulFW gebracht.

Du fragst mich sachen... Ich kenne das device nicht.
Aber 733Mhz ist glaube ich gar kein zugelassenes Band in Deutschland...

Gesendet von meinem Mobile Device.

Master_Nick · 21 Februar 2017, 14:24:26

Sorry ich meinte 433.

Aber generell, wenn ein Device in der normalen CulFW drin ist sollte es doch einfach zu implementieren sein oder?
Vorarbeit würde ich versuchen bestmöglich zu machen.

Hier gibt es wohl schon was dafür: https://github.com/btodcox/BBQduino

Hier auch das Protokoll: https://github.com/RFD-FHEM/RFFHEM/issues/61

Da wurde sich auch schon in meinem vorher verlinkten Thread gefragt, ob es inkludiert werden könnte.
Ich habe das Maverick ET-732 und hätte wohl auch Zugriff auf ein 733 um es zu testen.

Ich teste nachher erst mal, ob es nicht schon abgefrühstückt ist habe folgendes gefunden wo es wohl in einem Modul schon drin wäre: https://forum.fhem.de/index.php/topic,22977.msg405353.html#msg405353

KölnSolar · 21 Februar 2017, 15:14:02

ZitatAber generell, wenn ein Device in der normalen CulFW drin ist sollte es doch einfach zu implementieren sein oder?

Das wäre (relativ) simpel

ZitatHatte das hier dazu gefunden: https://forum.fhem.de/index.php/topic,51128.msg565659.html#msg565659

Da heißt es, es wurde in die CulFW gebracht.

Wo heißt es das ?

Da steht nix von "in die culfw gebracht".
Grüße Markus

Master_Nick · 21 Februar 2017, 15:17:44

Stimmt, das war mein Wunschgedanke

,

da stand es wäre zu tun... sorry. Aber eventuell ist es mit anderen Modulen in FHEM schon erledigt - ich teste nachher erst mal.

Peter_Listig · 21 Februar 2017, 19:07:32

Liebe Mitstreiter,

ich such mir seit einigen Tagen einen Wolf,
weil der Großteil meiner Temperatursensoren
nicht mehr angezeigt wird (siehe auch mein
Post an Bjoern hier auf Seite 91) ...

Ich bin am verzweifeln, inzwischen kann ich
auch nicht mehr übers Handy zugreifen.

Fhem hat noch den Stand 5.7 mit allen updates
davor.

Meinen CUL433 habe ich auf die Version 1.23.09
Build 194 geflasht - alles ohne Erfolg.

Danke für Eure Hilfe

Peter

bjoernh · 21 Februar 2017, 19:19:54

Zitat von: Peter_Listig am 21 Februar 2017, 19:07:32
Liebe Mitstreiter,

ich such mir seit einigen Tagen einen Wolf,
weil der Großteil meiner Temperatursensoren
nicht mehr angezeigt wird (siehe auch mein
Post an Bjoern hier auf Seite 91) ...

Ich bin am verzweifeln, inzwischen kann ich
auch nicht mehr übers Handy zugreifen.

Fhem hat noch den Stand 5.7 mit allen updates
davor.

Meinen CUL433 habe ich auf die Version 1.23.09
Build 194 geflasht - alles ohne Erfolg.

Danke für Eure Hilfe

Peter

Hast Du mal die vorherige Firrmware probiert?
Es wurde soweit ich es weiß nichts an den Empfangsroutinen geändert.

Hast Du den CUL mal neu initialisiert mit "raw e"?

Peter_Listig · 21 Februar 2017, 22:41:09

... also

raw e hat nix gebracht.
Hab mal eine Sicherung meiner cfg aus Januar
reinkopiert
Damit werden 4 Sensoren erkannt,
3 x
CODE SD_WS07_TH_841 u. 2 andere
NAME SD_WS07_TH_841
1 x
CODE CUL_TCM97001_35
NAME Mebus_35

die restlichen 7 nicht
1 x
CODE CUL_TCM97001_84
NAME NC_WS_84
6 x
CODE SD_WS07_TH_7B1 u.a.
NAME SD_WS07_TH_7B1

Wenn ich den CUL433 auf X25 und verbose 5 setze hagelt es Fehlermeldungen p11 u p 9 und IT_V3

2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 256 2576 240 320 224 1264 65 1 8 1 240 10144 0 03 B2B52AAB2CD4CACB00
2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 256 2592 224 304 240 1280 65 1 8 1 240 10160 0 03 B2B52AAB2CD4CACB00
2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 240 2640 240 320 240 1264 65 1 8 1 256 9504 0 05 FAFDAAABACD4CACB00
2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 224 2608 224 336 208 1280 65 1 8 1 240 10160 0 03 B2B52AABACD4CACB00
2017-02-21 22:19:47 Global global UNDEFINED IT_V3_11c01741 IT 01000111000000000101110100 0 001
2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 240 2592 240 320 240 1248 65 1 8 1 224 10128 0 05 B2B52AABACD4CACB00
2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 240 2624 256 320 240 1264 65 1 8 1 224 10112 0 03 B2B52AAB2CD4CACB00
2017-02-21 22:19:47 CUL CUL433 UNKNOWNCODE p 9 256 2592 224 320 224 1296 65 1 8 1 240 9472 0 07 B2B52AABACD4CACB00
2017-02-21 22:19:48 CUL CUL433 UNKNOWNCODE p 9 224 2608 224 320 208 1280 65 1 8 1 224 10128 0 07 B2B5AAABACD4CACB00

Als vorletzte Möglichkeit bleibt mir noch das Zurückspielen eines BackUps (wenn ich das hinbekomme),
bevor ich den raspi neu mit fhem 5.8 aufsetze ...

Vielleicht fällt Dir (Björn) oder Euch noch was dazu ein

Jedenfalls vielen Dank schon mal

Peter

Master_Nick · 22 Februar 2017, 09:50:09

Ich bin da jetzt noch nicht die Koryphäe auf dem Gebiet - arbeite mich Stück für Stück weiter ein und versuche zu verstehen....

Empfangen tut der CUL ja - ist dann nicht die Protokoll Erkennung im CUL das Problem?
So wie ich das bisher begriffen habe, läuft es ja so:

Signal empfangen -> CUL erkennt Protokoll -> Weiterleitung an Modul in FHEM -> Verarbeitung in FHEM

Hast ggfs. selber kompliliert und Protokolle ausgeschaltet im Cul?

RaspiLED · 22 Februar 2017, 15:18:54

Korrekt und hier die Unknown Codes sagen fhem Module fehlen. Neben dem Update von fhem auch in fhem selbst ein update durchgeführt und die module eingespielt?
Gruß Arnd

Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...

JWRu · 22 Februar 2017, 16:16:32

Auch ich habe Probleme mit einem Oregon THGR810 Temperatur/Feuchtesensor. Der CUL erkennt regelmäßig Funkpakete, kann sie anscheinend aber nicht dem richtigen Protokoll (Oregon V3) zuordnen.

Log mit set raw X25 und verbose 5:

2017.02.22 16:06:22 5: CUL/RAW: /omAAAAAAAAAAAAAA0C
2017.02.22 16:06:22 4: CUL_Parse: CUL_0 omAAAAAAAAAAAAAA0C
2017.02.22 16:06:22 5: CUL_0: dispatch omAAAAAAAAAAAAAA0C
2017.02.22 16:06:22 5: CUL_REDIRECT (mAAAAAAAAAAAAAA0C) length: 17 RSSI: -68
2017.02.22 16:06:22 5: CUL_REDIRECT (mAAAAAAAAAAAAAA0C) match Manchester COODE length: 17
2017.02.22 16:06:22 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAAAAAAAA0C)
2017.02.22 16:06:22 5: bitdata: 1010101010101010101010101010101010101010101010101010101000001100
2017.02.22 16:06:22 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAAAAAAAA0C)
2017.02.22 16:06:22 5: bitdata: 1010101010101010101010101010101010101010101010101010101000001100
2017.02.22 16:06:22 5: CUL_REDIRECT decode Hideki (AAAAAAAAAAAAAA0C)
2017.02.22 16:06:22 5: CUL_0: search in 1010101010101010101010101010101010101010101010101010101000001100
2017.02.22 16:06:22 5: protocol does not match, ignore received package (AAAAAAAAAAAAAA0C) Reason: Not a hideki protocol
2017.02.22 16:06:22 5: CUL/RAW: /p13 384 576 624 768 0 0 56 1 7 0 384 576 384 08 AAAAAAAAAAAAAA
2017.02.22 16:06:22 4: CUL_Parse: CUL_0 p13 384 576 624 768 0 0 56 1 7 0 384 576 384 08 AAAAAAAAAAAAAA
2017.02.22 16:06:22 5: Starting notify loop for CUL_0, 1 event(s), first is UNKNOWNCODE p13 384 576 624 768 0 0 56 1 7 0 384 576 384 08 AAAAAAAAAAAAAA
2017.02.22 16:06:22 5: createNotifyHash
2017.02.22 16:06:22 5: End notify loop for CUL_0
2017.02.22 16:06:22 2: CUL_0: unknown message p13 384 576 624 768 0 0 56 1 7 0 384 576 384 08 AAAAAAAAAAAAAA

V 1.23.09 a-culfw Build: 194 (2017-02-09_21-39-06) CUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB

Bennemannc · 22 Februar 2017, 17:04:36

Hallo,

ich hatte mal einen SIGNALduino und einen CUL433 zusammen laufen. Bei dem CUL hatte ich - außer schlechteren Empfang (weniger Daten) auch diese Probleme. Der duino läuft für den reinen Empfang von Temperatursensoren besser. Was er auf anderem Gebiet macht, weiß ich nicht. Angeblich geben beide Module die Daten ja nur durch zum Oregon Modul - die Frage wäre also warum klappt das beim duino besser als beim CUL.

Gruß Christoph

bjoernh · 22 Februar 2017, 17:39:05

Zitat von: Bennemannc am 22 Februar 2017, 17:04:36
Hallo,

ich hatte mal einen SIGNALduino und einen CUL433 zusammen laufen. Bei dem CUL hatte ich - außer schlechteren Empfang (weniger Daten) auch diese Probleme. Der duino läuft für den reinen Empfang von Temperatursensoren besser. Was er auf anderem Gebiet macht, weiß ich nicht. Angeblich geben beide Module die Daten ja nur durch zum Oregon Modul - die Frage wäre also warum klappt das beim duino besser als beim CUL.

Gruß Christoph

Weil der Duino eine komplett andere Empfangsverarbeitung hat. Er reicht die Daten an ein Modul weiter, welches diese dann analysiert.
Der CUL macht das im Prozessor, wodurch mangels Zeit nicht auf eine großartige Unterscheidung der Protokolle eingegangen werden kann.
Wem der Emfang also nicht reicht muss den Duino nehmen, oder damit leben

Dafür kann der CUL Homematic/MAX usw. perfekt.