Alternative culfw

jove01 · 14 Januar 2017, 14:21:33

Hallo

ich habe alle Schalter nochmals gelöscht, den CUL neu initialisiert und neu eingebunden etc.

Eigentlich nichts Neues, Doch irgendwann

Code Auswählen

2017.01.14 14:14:33 5 : CUL/RAW: /i501451FB
2017.01.14 14:14:33 4 : CUL_Parse: CUL_1_433 i501451FB -76.5
2017.01.14 14:14:33 5 : CUL_1_433: dispatch i501451
2017.01.14 14:14:33 4 : CUL_1_433 IT: message "i501451" (7)
2017.01.14 14:14:33 4 : CUL_1_433 IT: msgcode "FF000FF0FF0F" (12) bin = 010100000001010001010001
2017.01.14 14:14:33 5 : CUL_1_433 IT: V1 housecode = FF000FF0FF onoffcode = 0F
2017.01.14 14:14:33 4 : CUL_1_433 IT: FF000FF0FF not defined (Switch code: 0F)

Aber kein Autocreate !?

Vielleicht tut sich ja irgendwann etwas.

Ralf9 · 14 Januar 2017, 19:52:44

Zitat von: RaspII am 13 Dezember 2016, 23:13:39
Hi nochmal,
Ich hab mir diese 433 Module mal bestellt (die sind ja super günstig)
Ich melde mich wenn ich weiß wie gut die sind.

kannst Du hier mit reinschauen
https://forum.fhem.de/index.php/topic,56606.msg561147.html#msg561147

Gruß Ralf

limats · 14 Januar 2017, 21:31:33

Hallo zusammen,

ich betreibe einen Nanocul mit der a-culfw V1.23.05 mit 433MHz.
Mich wundert, dass die LED quasi dauernd leuchtet und nur ganz selten für den Bruchteil einer Sekunde aus geht.
Konfiguriert hab ich natürlich l00 und wenn ich die Antenne abschraube, geht die LED auch aus.
Kann mir aber nicht vorstellen, dass auf der Frequenz non-stop was los ist.
Auch wenn ich X25 einstelle, habe ich längere Pausen im Log in denen nach meinem Verständnis die LED nicht leuchten sollte, oder?
Bin mir auch relativ sicher, dass das früher nicht so war.

Viele Grüße
Leo

bjoernh · 14 Januar 2017, 21:41:08

Zitat von: limats am 14 Januar 2017, 21:31:33
Hallo zusammen,

ich betreibe einen Nanocul mit der a-culfw V1.23.05 mit 433MHz.
Mich wundert, dass die LED quasi dauernd leuchtet und nur ganz selten für den Bruchteil einer Sekunde aus geht.
Konfiguriert hab ich natürlich l00 und wenn ich die Antenne abschraube, geht die LED auch aus.
Kann mir aber nicht vorstellen, dass auf der Frequenz non-stop was los ist.
Auch wenn ich X25 einstelle, habe ich längere Pausen im Log in denen nach meinem Verständnis die LED nicht leuchten sollte, oder?
Bin mir auch relativ sicher, dass das früher nicht so war.

Viele Grüße
Leo

Habs gefunden, werde es bei Gelegenheit beheben.

jove01 · 14 Januar 2017, 22:57:53

Das mit den den Led war mir aufgefallen, dachte es hängt mit meinen Problemen zusammen.

Hallo Ralf9
Das mit dem Selbstbau-Cul hatte ich zuvor versucht gemäß verschiedener Blogs. Zum einen hatte ich damit ganz verschiedene Frequenzen, zum anderen hatte ich damit auch keinen Empfang.

cyablo · 19 Januar 2017, 13:00:43

Zitat von: Sidey am 06 Dezember 2016, 20:37:03
Das Problem mit dem Struct ist, dass die Daten sequentiell an den CUL übergeben werden.
Der kann das dann nicht verarbeiten und es kommt zu Datensalat.

Im Signalduino wurde das gelöst indem die Befehle in eine Warteschlange gelegt werden.

Grüße Sidey

Sorry das ich das Tema noch mal wieder ausgrabe: Mir ist jetzt mal aufgefallen dass das nicht am struct selbst liegt. Wenn ich z.B. mehre Dosen nach Sonnenaufgang schalten lassen, klappt das auch nur wenn mehre Sekunden Verzögerung mit einbaue (sunrise(), sunrise(+5), sunrise(+10)...)

blueberry63 · 19 Januar 2017, 13:12:34

Probier mal:

attr async_delay=xxx

Gruß
Blueberry63

cyablo · 19 Januar 2017, 15:21:48

Hatte ich bei den structs so verwendet. Ändert aber am Grundproblem nichts, mehrere Dosen per struct oder auch per Zeitschaltung lassen sich nur mit mehreren Sekunden Verzögerung nacheinander schalten (Bin aktuell bei 5 Sekunden und das klappt auch nur zu gefühlt 98%, hin und wieder bleibt mal eine Lampe AN/AUS).

EDIT: Über das Webinterface kann ich die Lampen beliebig oft nahezu beliebig schnell schalten. Ich gehe also auch nicht von einem aCULFW Problem aus. Jemand eine Idee in welchen Bereich das fallen könnte?

tkaiser · 21 Januar 2017, 21:44:24

Hallo,
Ich hätte mal eine Frage, ich habe mir gestern einen Funk Rauchmelder von uniTEC Model: LM-101LD gekauft.
Ist es möglich den in Fhem einzubinden ? Leider erkennt mein nanoCUL (433MHz) mit der aktuellen alternativen fw
den Rauchmelder nicht
Gruß
tkaiser

Doneli · 22 Januar 2017, 16:55:46

Hallo Miteinander,
ich habe mir 3 Funksteckdosen des Typs: Arendo gekauft. Siehe: https://www.amazon.de/Arendo-Funksteckdosen-Set-Funkschalter-Steckdosenset-LED-Statusanzeige-Kindersicherungsschutz/dp/B01GQFJVC0/ref=sr_1_1?ie=UTF8&qid=1485100187&sr=8-1&keywords=arendo+funksteckdosen+set
Diese zeichnen sich dadurch aus, dass sie bei günstigem Preis auch Lasten mit bis zu 3680 Watt schalten können (ich hatte aus Versehen eine Funksteckdose von Brennenstuhl schon gegrillt).
Ich hatte die Hoffnung dass ich diese mit meinem nanoCul mit der neuesten a-culfw ansteuern kann da diese denen von Revolt zum verwechseln ähnlich sehen.
Leider bekomme ich im Event Monitor von fhem nur folgende Ausgabe wenn ich die Steckdosen mit der Fernbedienung ansteuere:

2017-01-22 16:54:12 CUL 433cul UNKNOWNCODE i88083f
2017-01-22 16:54:13 CUL 433cul UNKNOWNCODE i88083d
2017-01-22 16:54:13 CUL 433cul UNKNOWNCODE i88083b

Scheinbar wird das Protokoll nicht unterstützt. Habe ich trotzdem eine Chance die Steckdosen irgendwie mit einzubinden?

Besten Dank im Voraus.

cs-online · 24 Januar 2017, 18:47:15

Hallo Doneli,

wenn das kein optischer Zufall ist und das Innenleben das selbe ist, dann sind das die Dinger, die bis vor kurzem im ACTION-Laden verkauft wurden, 3 Stück für 9,99... leider gibt's die da nicht mehr... Die konnte man mit einer IT-Fernbedienung anlernen und dann über CUL-FW oder A-CUL-FW schalten. Meine schalten relativ zuverlässig mit dem Nano-CUL und CUL-FW. Blöderweise kann man die nicht über FHEM mittels IT-Code direkt anlernen, weil die anscheinend einen langen Impuls brauchen und das (zumindest zu der Zeit, wo ich das probiert habe) nicht ging...

Grüße

Christian

HomeAuto_User · 26 Januar 2017, 20:12:50

Hallo,

die CUL-Firmware wurde gebugt in der Descriptors.c

#ifdef MULTI_FREQ_DEVICE
if (!bit_is_set(PINB, PB6))
Address = DESCRIPTOR_ADDRESS(ProductString433);

in

#ifdef MULTI_FREQ_DEVICE
if (!bit_is_set(MARK433_PIN, MARK433_BIT))
Address = DESCRIPTOR_ADDRESS(ProductString433);

Version 1.67 (2016-11-23)
- Hoermann Send (activated for CUL + nanoCUL)
- RFR filter: ufKERV forwards only messages starting with one of KERV
- Make EnoceanPI SCC compatible by hermi (Forum #60028)
- Fix the 433 PIN-check for "non-stdard" devices.

Da das bei mir der Grund für ein Fehlverhalten war und ich deine FW nutze,
so BITTE ich dich, das in dein a-culfw zu integrieren.

MfG

bjoernh · 26 Januar 2017, 22:38:54

Zitat von: HomeAuto_User am 26 Januar 2017, 20:12:50
Hallo,

die CUL-Firmware wurde gebugt in der Descriptors.c

#ifdef MULTI_FREQ_DEVICE
if (!bit_is_set(PINB, PB6))
Address = DESCRIPTOR_ADDRESS(ProductString433);

in

#ifdef MULTI_FREQ_DEVICE
if (!bit_is_set(MARK433_PIN, MARK433_BIT))
Address = DESCRIPTOR_ADDRESS(ProductString433);

Version 1.67 (2016-11-23)
- Hoermann Send (activated for CUL + nanoCUL)
- RFR filter: ufKERV forwards only messages starting with one of KERV
- Make EnoceanPI SCC compatible by hermi (Forum #60028)
- Fix the 433 PIN-check for "non-stdard" devices.

Da das bei mir der Grund für ein Fehlverhalten war und ich deine FW nutze,
so BITTE ich dich, das in dein a-culfw zu integrieren.

MfG

Ich ziehe es bei Gelegenheit nach. (mache ich ja von Zeit zu Zeit sowieso

)

HomeAuto_User · 26 Januar 2017, 23:23:21

Nabend,

ich bin schon wieder am tüfteln und probieren bzw. lesen.
Die Firmware a-culfw | CUL ist in Verwendung und nun kommen einigen Sensoren, vermutlich Hideki | TS04 unbekannter Code.

2017-01-26_23:03:44 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:06:32 Unknown Code: AFAFE81468
2017-01-26_23:06:32 Unknown Code: AFAFE81468
2017-01-26_23:07:07 Unknown Code: AA7FDE0250
2017-01-26_23:07:28 Unknown Code: AFAFE81468
2017-01-26_23:07:28 Unknown Code: AFAFE81468
2017-01-26_23:07:28 Unknown Code: AFAFE81468
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:41 Unknown Code: A90FD9A220

wo liegt mein Fehler?

bjoernh · 27 Januar 2017, 06:49:07

Zitat von: HomeAuto_User am 26 Januar 2017, 23:23:21
Nabend,

ich bin schon wieder am tüfteln und probieren bzw. lesen.
Die Firmware a-culfw | CUL ist in Verwendung und nun kommen einigen Sensoren, vermutlich Hideki | TS04 unbekannter Code.

2017-01-26_23:03:44 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:04:40 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:05:36 Unknown Code: AFAFE81468
2017-01-26_23:06:32 Unknown Code: AFAFE81468
2017-01-26_23:06:32 Unknown Code: AFAFE81468
2017-01-26_23:07:07 Unknown Code: AA7FDE0250
2017-01-26_23:07:28 Unknown Code: AFAFE81468
2017-01-26_23:07:28 Unknown Code: AFAFE81468
2017-01-26_23:07:28 Unknown Code: AFAFE81468
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:40 Unknown Code: A90FD9A220
2017-01-26_23:08:41 Unknown Code: A90FD9A220

wo liegt mein Fehler?

An der fehlenden Implementation im Fhem Modul. Die Firmware empfängt nur und reicht weiter. Fhem kann jetzt mit den Daten nichts anfangen.
D.h. jemand muss das Modul erweitern