Alternative culfw

Begonnen von bjoernh, 15 März 2015, 12:01:06

Vorheriges Thema - Nächstes Thema

Talkabout

Hallo zusammen,

mein Fix oben ist auch nicht der Weissheit letzter Schluss. Gerade eben hatte ich den Fall, dass die invalide Temperatur ohne das "mode" "force" ankam. Demnach wäre es noch eine Möglichkeit die Plausibilitätsprüfung bei allen Devices zu machen. Da bräuchte ich aber die Meinung des Modul-Maintainers.

Gruss

Peter_Listig

Schönen guten Abend werte Mitstreiter,

ein kurze und sich auch schnell zu beantwortende Frage:

Kann es sein, dass "Eurochron" Sensoren nicht mehr als
"SD_WS07_TH_721" erkannt werden ?  z.B.


define SD_WS07_TH_721 SD_WS07 SD_WS07_TH_721
attr SD_WS07_TH_721 event-min-interval .*:300
attr SD_WS07_TH_721 event-on-change-reading .*
attr SD_WS07_TH_721 room SD_WS07


sondern wieder wie wie "füher"als


define CUL_TCM97001_214 CUL_TCM97001 214
attr CUL_TCM97001_214 model Eurochron
attr ...


erkannt werden ?

Wenn ja was ist der Hintergrund - ich habe wahrscheinlich etwas verpasst !

Vielen Dank schon mal

Grüße

Peter

Raspi4 / Debian Bullseye / FB 7490 / FHEM 6.x / CUL433 / CUL868 / aculfw / FrtizFon / DECT200 / IT / Homematic / ZigBee (Raspbee) /  Rademacher / HE / km200  / DS214+

bjoernh

Zitat von: Peter_Listig am 30 Januar 2016, 18:17:50
Schönen guten Abend werte Mitstreiter,

ein kurze und sich auch schnell zu beantwortende Frage:

Kann es sein, dass "Eurochron" Sensoren nicht mehr als
"SD_WS07_TH_721" erkannt werden ?  z.B.


define SD_WS07_TH_721 SD_WS07 SD_WS07_TH_721
attr SD_WS07_TH_721 event-min-interval .*:300
attr SD_WS07_TH_721 event-on-change-reading .*
attr SD_WS07_TH_721 room SD_WS07


sondern wieder wie wie "füher"als


define CUL_TCM97001_214 CUL_TCM97001 214
attr CUL_TCM97001_214 model Eurochron
attr ...


erkannt werden ?

Wenn ja was ist der Hintergrund - ich habe wahrscheinlich etwas verpasst !

Vielen Dank schon mal

Grüße

Peter
Es wurde nicht diesbezüglich geändert. 

Temudshin

Hallo,
ich verfolge diesen Thread schon eine ganze Weile und muß sagen, die meisten meiner Fragen konnte ich hier finden ! Super Arbeit, die hier geleiset wird.
FHEM werkelt bei mir auf einem Raspi und ein CUL 433MHz übernimmt derzeit die Koomunikation zu verschiedenen Komponenten. (a-culfw ist Version 1.20.4)

Heute kam diese Meldung rein, im Log-File:
CUL_TCM97001 Unknown device CUL_TCM97001_157, please define it
hat jemand eine Idee, welches Gerät das sein könnte ? Ich spekuliere auf den Regensensor meiner Auriol Wetterstation, oder deren Windmesser, kann das sein ? Wenn ja, weiß jemand welche Paramter ich einstellen muß um die Werte zu bekommen ? (FHEM update hab ich heute morgen gemacht)

Mein zweites Anliegen wäre bzgl. meiner Auriol...
Meine Auriol ist auch erkannt, allerdings zeigt mir der Temperatur Sensor "-" Temperatur Werte an, die so um die 8° bis 10° daneben liegen. (es wir -3°C angezeigt, dabei sind es +5°C)
Der CUL liefert diese Rohdaten:
CUL_0_RAWMSG           s3AFFE1FA70EF; 224: 8000
ich denk ich hab das was in den Attr. übersehen ? Kann mir jemand Erleuchtung bringen ?
Vielen dank für Eure Hilfe !
Gruß
Juergen

Peter_Listig

@Bjoern

Hallo Bjoern,

leider werden bei mir keine IT Devices mehr per autocreate angelegt.
Ich habe mein Wheezy und damit auch fhem zerschossen und musste
neu aufsetzen ...
Muss ich für die Erkennung noch die gepatchte "14_CUL_TCM97001"
einspielen, damit das ganze wieder funzt ?

Gruß

Peter
Raspi4 / Debian Bullseye / FB 7490 / FHEM 6.x / CUL433 / CUL868 / aculfw / FrtizFon / DECT200 / IT / Homematic / ZigBee (Raspbee) /  Rademacher / HE / km200  / DS214+

masterpete23

Peter welche Version hast du denn geflasht?

Gesendet von meinem Huawei Honor 7


Peter_Listig

Hallo,

meine Konfiguration anbei ...
CUL433 mit Version:
V 1.10.01 a-culfw Build: 167 (2015-10-13_18-19-02) CUL433 (F-Band: 433MHz)
CUL868mit Version:
V 1.61 CUL868
Wheezy
und fhem 5.7
alles zusammen auf einem Raspi2

Bis zum Crash ist alles perfekt gelaufen.
Irgendwo habe ich Dussel was übersehen!

Danke für Eure Hilfe

Gruß

Peter

Raspi4 / Debian Bullseye / FB 7490 / FHEM 6.x / CUL433 / CUL868 / aculfw / FrtizFon / DECT200 / IT / Homematic / ZigBee (Raspbee) /  Rademacher / HE / km200  / DS214+

johannes.knofe

Hallo und schönen Sonntag,

ich nutze nun auch seit ein paar Tagen die a-culfw auf einem Arduino MircoPro 3.3V mit CC1101-433Mhz und ich empfange mit der a-culfw 1.20 allerlei mir unbekannte Pakete auf 433,92MHz, hat jemand ein Idee was das sein könnte? Für FHEM scheinen diese nicht relevant zu sein, zumindest der autocreate springt nich darauf an:

mit X21

omA01C02BED8
omA01C02BED8
omA01C02BCD8
omA01C02BED8
omA01C02BED6


mit X04

p11  112 4304   48 2032   16  560 214  1 26 6   752  4720     0 EBEE695AEF57D76CDEFB7356BB6EF7A7BCDF7D3A7BFFFB6ACEB674
p13 1296 1232  864  784    0    0  31  1  3 7  1488  1424   736 A01C02BE
p13 1296 1424  848  784    0    0  31  1  3 7  1488  1424   736 A01C02BE
p13 1296 1424  848  784    0    0  31  1  3 7  1488  1424   736 A01C02BE
p13 1296 1424  864  784    0    0  31  1  3 7  1488  1424   736 A01C02BE
p11  160  320  608 3152   48  624  80  1 10 0   752  6816     0 39F0EDD9D02FECB7D8E9


wie muss ich die Ausgaben bei X04 lesen? so richtig bin aus der commandref.html allein nich schlau geworden? Was für eine Art ist ein Paket das mir die a-culfw mit omXXXXXXXX anzeigt?

Peter_Listig

Nachtrag

Hab heute nochmal komplett neu aufgesetzt ...
... läuft wieder wie bisher  :) :)

keine Ahnung warum - hab nichts anders gemacht wie vorher ???  :(

der CUL433 habe ich zum Testen gerade auf Version
V 1.20.04 a-culfw Build: 167 (2015-10-13_18-19-02) CUL433 (F-Band: 433MHz)
geflasht.

Trotzdem Danke an alle

Gruß
Peter

Raspi4 / Debian Bullseye / FB 7490 / FHEM 6.x / CUL433 / CUL868 / aculfw / FrtizFon / DECT200 / IT / Homematic / ZigBee (Raspbee) /  Rademacher / HE / km200  / DS214+

luke666s

#759
bei mir wird der wettersensor von tchibo/aldi (prologue protkoll) nicht gefunden... bzw er erstellt kein device dazu.

2016.01.31 17:01:17 3: CUL0: Unknown code s91C0047548FA;  512: 9104, help me!
2016.01.31 17:02:57 3: CUL0: Unknown code s91C0047548F8;  496: 9104, help me!
2016.01.31 17:03:47 3: CUL0: Unknown code s91C0047548FA;  512: 9104, help me!
2016.01.31 17:04:37 3: CUL0: Unknown code s91C0047548FA;  480: 9120, help me!


von der rechnerei passen die werte 7,1°C und 87%

UPDATE: Gelöst.... das neue FHEM ausm SVN genommen und die devices werden wieder angelegt :)

Willi

Hallo,

nachdem ich längere Zeit nicht mehr im Forum aktiv war, habe ich von dieser alternativen-Firmware erfahren und mir kurz https://github.com/heliflieger/a-culfw angesehen.

Wo sind denn die alternativen Protokolle dokumentiert, also wie diese codiert werden?

Normalerweise ist das in der commandref.html (siehe auch http://culfw.de/commandref.html) dokumentiert. Ich finde dazu aber nichts in der a-culfw zu den neuen Protokollen.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

rubbertail

#761
Schönen guten Tag,

hat möglicherweise jemand von euch ein ähnliches Problem?
Ich habe heute auf meine CUL433 und CUL868 die neu compilierte a-culfw 1.20.04 aufgespielt - und mich erstmal gefreut, dass damit meine ollen FLS 100 IT-Steckdosen wieder so schalten wie mit der 1.10.02.
Allerdings scheint es mir, als hätte die FW nun ein Problem mit MAX - ist das möglich? Ich hatte im Log plötzlich Fehler wie
2016.02.01 11:33:18 2: CUL_MAX_SendQueueHandler: Missing ack from 0392b1 for 0faa04031234560392b10010010b218f
für mehrere meiner MAX-Komponenten (die vorher sauber gepaired waren und gesteuert wurden).

Beim Versuch eines Re-Pairings eines der Komponenten (ein Wandtthermostat - hab natürlich auf genügend Credits geachtet etc.) klappt das Pairing allerdings nicht, und im Log finde ich zu genau diesen Zeitpunkten folgende Einträge:
2016.02.01 11:20:56 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!
2016.02.01 11:21:01 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!
2016.02.01 11:21:06 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!
2016.02.01 11:21:11 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!
2016.02.01 11:21:16 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!
2016.02.01 11:21:21 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!
2016.02.01 11:21:26 3: CUL868: Unknown code Z1700040002B5EE000000001203FF49455130343932393932, help me!


Dazu kommen laufend Einträge wie
2016.02.01 11:35:51 3: CUL868: Unknown code Z0CB3044202ACE80398230022D8, help me!
2016.02.01 11:35:51 3: CUL868: Unknown code Z0EB3020203982302ACE80001180022, help me!
2016.02.01 11:35:54 3: CUL868: Unknown code Z0C23044202B0D503A02E0022D1, help me!
2016.02.01 11:35:54 3: CUL868: Unknown code Z0E23020203A02E02B0D50001180522, help me!
2016.02.01 11:35:58 3: CUL868: Unknown code Z0C9E044202AC680392B10022C9, help me!
2016.02.01 11:35:58 3: CUL868: Unknown code Z0E9E02020392B102AC680001181422, help me!
2016.02.01 11:36:19 3: CUL868: Unknown code Z0B1D063000F4F91234560012, help me!
2016.02.01 11:36:22 3: CUL868: Unknown code Z0C8F044202B5EE0000000022EA, help me!
2016.02.01 11:36:22 3: CUL868: Unknown code Z0F01046000E4C90000000018002200EA, help me!

die ich zeitlich höchtens den MAX-Komponenten zuordnen könnte...

Ist das möglich? Hab ich irgendwas verbockt (gut möglich, ich fuchse mich in SEHR kleinen Schritten in die ganzen FHEM-Themen ein)? Kenn ich mich zuwenig aus (Klares Ja!)?

Wäre um jede Hilfe sehr dankbar...

Update:
OK, wieder ich selber doof...

Nach dem FW-Upgrade war der rfmode nicht mehr auf MAX gesetzt (wieso das so war, weiß ich nicht wirklich). Nach einem

attr CUL868 rfmode MAX

Geht nun alles, und das Log ist auch wieder beruhigt.

Nunja, was gelernt. %)

Martin
FHEM auf Raspi, CUL433, CUL868, RFXTRX433e, CULCuBE
FRITZ: Fritzbox7590AX, 6xFritzDECT301, 10xFritzDECT200, FritzRepeater 6000
MAX!: Fensterkontakte
netatmo: Wetterstation & Thermostat
Milights, IT, Withings, HUE

Bootscreen

#762
Hallo,

gibt es eine Möglichkeit 433Mhz Raw Befehle in folgender Form zu senden, oder kann mir jemand sagen wie ich daraus diesen G befehl der culfw bastel?
231 693 231 693 231 693 693 231 231 693 231 693 231 693 231 693 231 693 231 693 231 693 693 231 231 693 231 693 231 693 693 231 231 693 231 693 231 693 231 693 693 231 693 231 231 693 231 693 231 7854

Nachtrag:
Mit X25 loggt er leider nichts und die LED meines nanoCUL's, die normalerweise flackert wenn sie ein Signal einer 433Mhz Fernbedienung empfängt, tut auch nichts.
Gruß
Oliver

FHEM 5.7 Hardware:
Raspberry PI B+ | HomeMatic USB 2 | 433Mhz Sender (pilight) | nanoCUL (433Mhz)

homeum

Ich habe nach einiger Zeit mal wieder mein Busware Cul433V3 auf die aktuelle a-culfw_1.20.04_build_180 aktualisiert.
Seit dem schalten meine Baumarkt-Funksteckdosen nicht mehr auf den fhem-Befehl.
Der Handsender wird noch immer empfangen und auch der Status in fhem wird umgeschaltet.

Ich habe nun auf die vorherige a-culfw_1.20.00_build_174 zurückgeflasht und alles funktioniert wieder korrekt.
Die 3 Kanäle wurden per autocreate als IT-Funksteckdosen angelegt, nur die on/off Befehle musste ich vertauschen, damit der Status und Sendebefehl stimmt.

Ob es was mit dem veränderten ITClock und/oder Angleichung an die originale culfw zu tun hat?
Mit der originalen Busware culfw werden die Steckdosen gar nicht erkannt.

Vorerst nutze ich also die a-culfw_1.20.00_build_174 weiter, wäre aber schön, wenn es auch mit den aktuellen Versionen wieder klappt.
Oder lässt es sich per Parameter anpassen?





bjoernh

Zitat von: homeum am 04 Februar 2016, 09:30:41
Ich habe nach einiger Zeit mal wieder mein Busware Cul433V3 auf die aktuelle a-culfw_1.20.04_build_180 aktualisiert.
Seit dem schalten meine Baumarkt-Funksteckdosen nicht mehr auf den fhem-Befehl.
Der Handsender wird noch immer empfangen und auch der Status in fhem wird umgeschaltet.

Ich habe nun auf die vorherige a-culfw_1.20.00_build_174 zurückgeflasht und alles funktioniert wieder korrekt.
Die 3 Kanäle wurden per autocreate als IT-Funksteckdosen angelegt, nur die on/off Befehle musste ich vertauschen, damit der Status und Sendebefehl stimmt.

Ob es was mit dem veränderten ITClock und/oder Angleichung an die originale culfw zu tun hat?
Mit der originalen Busware culfw werden die Steckdosen gar nicht erkannt.

Vorerst nutze ich also die a-culfw_1.20.00_build_174 weiter, wäre aber schön, wenn es auch mit den aktuellen Versionen wieder klappt.
Oder lässt es sich per Parameter anpassen?

Hast Du mal die ITClock verstellt?
Die Baumarkt Steckdosen brauchen meist ein kürzeres Timing