Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

Begonnen von Sidey, 02 Oktober 2016, 23:39:11

Vorheriges Thema - Nächstes Thema

bitbiter


Hallo Sidey.

Nach einem "update all" heute morgen habe ich zigfach (2x bis 6x / min) im Log folgende Meldung:

2016.12.05 08:38:58 1: ERROR: >Unknown, please report< returned by the SIGNALduino_un ParseFn is invalid, notify the module maintainer

Selbst nach einem "shutdown restart" bleibt die Meldung. Und da du der "Maintainer" bist (wenn ich mich nicht irre), hab ich dich hiermit informiert.  ;)

Gruss aus dem kalten Hessen
Alex
Raspi mit Homematic-CCU, KeyMatic mit FB, HM-SEC-MDIR-2, HM-Sec-Sco, HM-MOD-RPI-PCB, 2x LCGW m. CUL868 / CUL433. == BananaPi mit fhem + SSD, MAX! FK und TS, Cube read-only (demn. Umstieg --> CUL), mehrere TFA/LC Sensoren, Milight Controller + Bulbs, Revolt, ECO Taster, Home-Easy, ESP8266 etc....

RappaSan

#31
Bei mir sieht's ähnlich aus...

2016.12.05 12:11:41 1: ERROR: >OREGON: ERROR: Unknown sensor_id=1a2d bits=72.
< returned by the OREGON ParseFn is invalid, notify the module maintainer
2016.12.05 12:12:20 1: ERROR: >T: 6.6 H: 77 BAT: low< returned by the OREGON ParseFn is invalid, notify the module maintainer
2016.12.05 12:12:21 1: ERROR: >OREGON: ERROR: Unknown sensor_id=1a2d bits=72.
< returned by the OREGON ParseFn is invalid, notify the module maintainer

2016.12.05 12:31:23 1: ERROR: >Wrong IT message received: 1DD11101DDDD< returned by the IT ParseFn is invalid, notify the module maintainer

Seitenweise...
Veränderung an der Konfig: keine.
Heute ist allerdings ein "update" gelaufen.

Da scheint etwas anderes im Busch zu sein...

Ralf9

Zitat von: RappaSan am 05 Dezember 2016, 12:28:39
2016.12.05 12:11:41 1: ERROR: >OREGON: ERROR: Unknown sensor_id=1a2d bits=72.
< returned by the OREGON ParseFn is invalid, notify the module maintainer
2016.12.05 12:12:20 1: ERROR: >T: 6.6 H: 77 BAT: low< returned by the OREGON ParseFn is invalid, notify the module maintainer
2016.12.05 12:12:21 1: ERROR: >OREGON: ERROR: Unknown sensor_id=1a2d bits=72.
< returned by the OREGON ParseFn is invalid, notify the module maintainer

Die Fehler im Oregon-Modul sind in der aktuellen dev-r33 behoben
https://forum.fhem.de/index.php/topic,58090.msg533359.html#msg533359

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

#33
Zitat von: RappaSan am 05 Dezember 2016, 12:28:39
Heute ist allerdings ein "update" gelaufen.

Da scheint etwas anderes im Busch zu sein...

Ja, Rudi hat da was eingebaut um einem Fehler auf die Schliche zu kommen.... 

Update im Master und auch im dev-r33 ist eingecheckt. Wenn ich eine positive Rückmeldung erhalte, dann checke ich es auch in fhem ein.

@Ralf: Wie machen wir das mit der 41_Oregon. Wir sind ja nicht die Maintainer.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Zitat von: Sidey am 05 Dezember 2016, 21:55:59
@Ralf: Wie machen wir das mit der 41_Oregon. Wir sind ja nicht die Maintainer.

Das müsste eigentlich der Maintainer Willi machen, aber Willi scheint schon einige Zeit nicht mehr im Forum aktiv zu sein.


Ich habe mal die restlichen Module durchgeschaut. Bei den folgenden Modulen hat es auch noch nicht zulässige returns:

14_Hideki.pm
return "$name Sensor Typ $sensorTyp not supported, please report sensor information!";

14_SD_AS.pm

14_SD_UT.pm
if (!defined($model)) {
return $dummyreturnvalue;
}


14_SD_WS.pm


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Zitat von: Ralf9 am 05 Dezember 2016, 23:57:52
Das müsste eigentlich der Maintainer Willi machen, aber Willi scheint schon einige Zeit nicht mehr im Forum aktiv zu sein.
Ich habe Willi eine Email geschrieben. Mal sehen ob er reagiert.
Sonst müssen wir halt einen neuen maintainer auswählen.

Die andeten Module kann ich heute Abend anpassen und dann auch die angepasste Version über das FHEM Update verteilen lassen.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Hallo Sidey,

bei Tests mit dem CC1101 ist mir aufgefallen, daß bei mir im Haus die beiden EAS800z vom CC1101 nicht empfangen werden. Der NC-7345 wird aber empfangen, obwohl beide das selbe Protokoll senden. Ein EAS800z war bei den Tests ca 2m vom CC1101 entfernt.
Ich hatte den Signalduino mit dem RXB6 Superheterodyne (sduinoE) und den Signalduino mit dem CC1101 (sduino) parallel inbetrieb.
Hast Du eine Idee an was das liegen könnte? Kannst Du am log was erkennen?
2016.12.09 18:34:54.036 4 : sduino/msg READ: MU;P0=852;P1=-935;P2=1991;P3=-3964;P4=6016;P5=-6420;P6=3456;P7=-2406;D=0121212121212121212345612721212121212121612767212121212121216761212127612;CP=2;
2016.12.09 18:34:55.599 4 : sduinoE/msg READ: MS;P0=-3575;P1=495;P2=-974;P3=-1943;D=10121313121212131213121213121212121313121313131212131313131212131312131313;CP=1;SP=0;O;
2016.12.09 18:34:55.600 4 : sduinoE: Matched MS Protocol id 7 -> weatherID7
2016.12.09 18:34:55.600 4 : sduinoE: Decoded MS Protocol id 7 dmsg P7#6290DCF37 length 36
2016.12.09 18:34:55.601 4 : SD_WS07_Parse SD_WS07 (P7#6290DCF37) length: 9
2016.12.09 18:34:55.601 4 : SD_WS07_TH decoded protocolid: 7 sensor id=62, channel=2, temp=22, hum=55, bat=ok
2016.12.09 18:34:55.784 4 : sduino/msg READ: MU;P0=-32001;P1=1996;P2=-931;P3=-3984;P4=6016;P5=-6412;P6=3458;P7=-2404;D=012121212121212121212121345621712121212121212621767121212121212126762121217621;CP=1;

2016.12.09 18:42:24.028 4 : sduino/msg READ: MU;P0=-2407;P1=112;P2=-4088;P3=5936;P4=-6472;P5=3462;P6=-930;P7=1983;D=012345670767676765676705050767676767676765670567670567;CP=7;
2016.12.09 18:42:44.293 4 : sduino/msg READ: MU;P0=920;P1=-4040;P2=5968;P3=-6444;P4=3471;P5=-930;P6=1989;P7=-2393;D=01234567656565654565674747656565656565654567456567456;CP=6;
2016.12.09 18:42:44.868 4 : sduinoE/msg READ: MS;P0=-967;P1=494;P2=-2064;P3=-3893;D=13101212101010121012101012101010101212101210121212121212121010121012121210;CP=1;SP=3;O;
2016.12.09 18:42:44.868 4 : sduinoE: Matched MS Protocol id 7 -> weatherID7
2016.12.09 18:42:44.868 4 : sduinoE: Decoded MS Protocol id 7 dmsg P7#6290D7F2E length 36
2016.12.09 18:42:44.869 4 : SD_WS07_Parse SD_WS07 (P7#6290D7F2E) length: 9
2016.12.09 18:42:44.869 4 : SD_WS07_TH decoded protocolid: 7 sensor id=62, channel=2, temp=21.5, hum=46, bat=ok




Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Ich habe es mir mobil angesehen.

So grob fällt mir auf, dass die Startsequenz beim cc1101 nicht passt.
Es müsste so was wie +500 -3500 empfangen werden.

Ist auf dem cc1101 vielleicht doch etwas aktiv, was die Daten verarbeitet?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

StefanW

Hallo,
ich habe vorhin mal wieder ein update gemacht und seit dem wird mir das log mit Meldungen dieser Art praktisch "zugemüllt".

2016.12.10 11:09:31 3: Sduino_IP: Unknown code u20#55555555550, help me!
2016.12.10 11:09:36 3: Sduino_IP: Unknown code u20#555104, help me!
2016.12.10 11:09:37 3: Sduino_IP: Unknown code u20#AAAAAAAAAAA8, help me!
2016.12.10 11:09:38 3: Sduino_IP: Unknown code u20#AAAAAAAA8, help me!
2016.12.10 11:09:45 3: Sduino_IP: Unknown code u20#55455550, help me!
2016.12.10 11:09:48 3: Sduino_IP: Unknown code u29#EFE, help me!
2016.12.10 11:09:49 3: Sduino_IP: Unknown code u20#AAA2AAAAAAAA, help me!
2016.12.10 11:09:51 3: Sduino_IP: Unknown code u20#515511555555554, help me!
2016.12.10 11:09:52 3: Sduino_IP: Unknown code u20#AAAAA8, help me!
2016.12.10 11:09:53 3: Sduino_IP: Unknown code u20#AAA9AAAAAA, help me!
2016.12.10 11:09:53 3: Sduino_IP: Unknown code u20#AAAAAA8AA2AA0, help me!
2016.12.10 11:09:56 3: Sduino_IP: Unknown code u20#AAAAAAAAAA8C, help me!
2016.12.10 11:09:57 3: Sduino_IP: Unknown code u20#AAAAAA2AAA8, help me!
2016.12.10 11:09:58 3: Sduino_IP: Unknown code u20#AAAA2AAAAAAAAAAAAAA, help me!
2016.12.10 11:09:59 3: Sduino_IP: Unknown code u20#AAAAAA2A6AAAAA428, help me!
2016.12.10 11:09:59 3: Sduino_IP: Unknown code u29#FFF, help me!
2016.12.10 11:10:01 3: Sduino_IP: Unknown code u20#55455555554, help me!
2016.12.10 11:10:02 3: Sduino_IP: Unknown code u20#AAAAAAA, help me!
2016.12.10 11:10:02 3: Sduino_IP: Unknown code u20#AAAAAAAAAAAA, help me!
2016.12.10 11:10:05 3: Sduino_IP: Unknown code u29#FFE, help me!
2016.12.10 11:10:05 3: Sduino_IP: Unknown code u20#A2AAAAAAA8, help me!
2016.12.10 11:10:06 3: Sduino_IP: Unknown code u20#AAAAAAAAAAAAAAAAA, help me!
2016.12.10 11:10:07 3: Sduino_IP: Unknown code u20#AAAAAAA, help me!
2016.12.10 11:10:07 3: Sduino_IP: Unknown code u20#555555555540, help me!
2016.12.10 11:10:11 3: Sduino_IP: Unknown code u20#AAAAAA2AAA, help me!
2016.12.10 11:10:13 3: Sduino_IP: Unknown code u20#55555555555, help me!
2016.12.10 11:10:15 3: Sduino_IP: Unknown code u20#A2A2AAAA28, help me!
2016.12.10 11:10:15 3: Sduino_IP: Unknown code u20#AAAAAAA422A, help me!
2016.12.10 11:10:15 3: Sduino_IP: Unknown code u20#AAAAAB2AB2A88A2A, help me!
2016.12.10 11:10:15 3: Sduino_IP: Unknown code u29#FFE, help me!
2016.12.10 11:10:16 3: Sduino_IP: Unknown code u20#1555555555, help me!
2016.12.10 11:10:19 3: Sduino_IP: Unknown code u20#555555554450, help me!
2016.12.10 11:10:21 3: Sduino_IP: Unknown code u20#54D55545514, help me!
2016.12.10 11:10:24 3: Sduino_IP: Unknown code u29#FFE, help me!
2016.12.10 11:10:29 3: Sduino_IP: Unknown code u20#5555515155551555554, help me!
2016.12.10 11:10:29 3: Sduino_IP: Unknown code u20#5555550, help me!
2016.12.10 11:10:30 3: Sduino_IP: Unknown code u20#5555584, help me!
2016.12.10 11:10:31 3: Sduino_IP: Unknown code u20#AAAAAA, help me!


Version aud dem Sinalduino ist die V 3.3.0.
Vor dem update war alles normal.

Gruß
Stefan

Ralf9

Zitat von: StefanW am 10 Dezember 2016, 11:19:37
ich habe vorhin mal wieder ein update gemacht und seit dem wird mir das log mit Meldungen dieser Art praktisch "zugemüllt".

Ich denke, die Ursache dafür dürfte eine Änderung sein, die Sidey vor ein paar Tagen gemacht hat.
Die Protocol Id 20 ist livolo. Wenn Du livolo nicht hast, dann kannst Du die vielen log Einträge mit dem Attribut whitelist_IDs wegbekommen.
In das Attribut whitelist_IDs kannst Du die Ids der Sensoren die Du hast Komma getrennt eintragen.
Mit get protocolIDs bekommst Du eine Liste aller Protocol Ids.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Zitat von: Sidey am 10 Dezember 2016, 10:44:51
Ist auf dem cc1101 vielleicht doch etwas aktiv, was die Daten verarbeitet?

Nein, es ist genauso wie bei der a-culfw der asynchronous serial mode. Bei der a-culfw wird der EAS800z auch nicht empfangen.
Hier ist ein Vergleich der beiden wie sie mit dem RXB6 empfangen werden.

FreeTec NC-7345 wird mit dem CC1101 empfangen
MS;P0=-1946;P1=497;P2=-1085;P3=-3892;D=13121212121212101212121212121212121012121010121010101010101212101210121010;CP=1;SP=3;O;
P7#02009BF2B


EAS800z wird mit dem CC1101 nicht empfangen
MS;P0=-1934;P1=-959;P2=500;P3=-3876;D=23212020212121202120212120212121212021202021202121202020202121202021212020;CP=2;SP=3;O;
P7#6290B4F33


Beide NC-7345 werden problemlos empfangen.
Meine GT-WT-2 werden auch problemlos empfangen.
Der Hama (Hideki) wird auch problemlos empfangen
MC;LL=-1043;LH=903;SL=-570;SH=407;D=A8E9345ADBDC0B197595E4C;C=487;L=90;

Kann dies ein Grund sein, warum bei mir der CC1101 den EAS800z nicht empfängt?
Zitat von: RaspII am 09 Dezember 2016, 17:53:03
Ich hatte in der Vergangenheit immer wieder Probleme mir den "blauen" CC1101 Modulen. Diese sind bzgl. Frequenz extrem ungenau, deshalb verwende i

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

StefanW

Zitat von: Ralf9 am 10 Dezember 2016, 22:57:01
Ich denke, die Ursache dafür dürfte eine Änderung sein, die Sidey vor ein paar Tagen gemacht hat.
Die Protocol Id 20 ist livolo. Wenn Du livolo nicht hast, dann kannst Du die vielen log Einträge mit dem Attribut whitelist_IDs wegbekommen.
In das Attribut whitelist_IDs kannst Du die Ids der Sensoren die Du hast Komma getrennt eintragen.
Mit get protocolIDs bekommst Du eine Liste aller Protocol Ids.

Gruß Ralf

Danke, das hat geholfen.  :D

Sidey



Zitat von: Ralf9 am 11 Dezember 2016, 01:00:23

MC;LL=-1043;LH=903;SL=-570;SH=407;D=A8E9345ADBDC0B197595E4C;C=487;L=90;

Kann dies ein Grund sein, warum bei mir der CC1101 den EAS800z nicht empfängt?
Gruß Ralf
Moin Ralf,

Probier doch mal mit deaktivieren MC Decoder aus, was empfangen wird.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Das deaktivieren des MC Decoder hat nichts gebracht.
Das Problem habe ich auch wenn ich die a-culfw flashe, dann wird der  EAS800z und NC-7345 gar nicht empfangen.
Ich denke ein Grund könnte sein, daß ich hier im Haus Funkstörungen habe und der RXB6 Superheterodyne empfängt bei Funkstörungen besser als der CC1101.
Da das hier leicht OT ist schreibe ich in "Bastelecke - SIGNALDuino Empfänger Firm- und Hardware" weiter.


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

prodigy7

Hallo zusammen!

Denkt ihr, es ist möglich, das quigg Protokoll zu implementieren? Die Funksteckdosen von Aldi funktionieren soweit ich das nachvollziehen konnte, wohl damit.
Aktuell ist es so, dass sich auf dem signalduino mid 433MHz im Log absolut gar nichts tut, wenn ich auf der Fernbedienung was drücke.
Im pilight Projekt ist das Protokoll bereits implementiert: https://github.com/pilight/pilight/blob/master/libs/pilight/protocols/433.92/quigg_gt1000.c

p7