Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[atmelfreak]

Einen Neustart habe ich schon gemacht, hat leider nichts gebracht. Kann man die Geräte auch händisch anlegen und wenn ja, wie?

[Sidey]

Scheinbar wird ja richtig dekodiert und es wird erkannt, dass es sich z.B. um eine Lidl Wetterstation handelt, aber es wird kein Gerät angelegt und im Eventlog erscheint auch nichts. Woran kann das liegen?

Ist autocreate noch aktiv?
So wie das im Log aussieht, wird autocreate nicht ausgelöst.
Entweder, weil es das gerät noch gibt, oder autocreate ist nicht aktiv.

Grüße Sidey

[RaspiLED]

Okay, was sagt ein "list autocreate"?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[Ralf9]

Ich vermisse im log das "UNDEFINED sensor SD_WS07_TH detected,..", es müsste so ausehen.

Code Auswählen Erweitern

2017.03.22 23:08:11.807 4: SD_WS07_TH decoded protocolid: 7 sensor id=73, channel=1, temp=9.8, hum=50, bat=ok
2017.03.22 23:08:11.807 1: SD_WS07: UNDEFINED sensor SD_WS07_TH detected, code SD_WS07_TH_1

Wenn dann innerhalb von 3 Minuten eine weitere Nachricht kommt, dann müsste er per autocreate angelegt werden.

Gruß Ralf

[atmelfreak]

list autocreate sieht so aus:

Code Auswählen Erweitern

Internals:
   NAME       autocreate
   NOTIFYDEV  global
   NR         14
   NTFY_ORDER 50-autocreate
   STATE      active
   TYPE       autocreate
Attributes:

[atmelfreak]

Nachdem ich das Device SD_WS_51_TH_1 gelöscht habe und FHEM neu gestartet habe, wurde das Gerät neu angelegt und bekommt auch wieder aktuelle Daten. Auch im Eventmonitor erscheinen jetzt die Daten des Sensors:

Code Auswählen Erweitern

2017-03-23 00:02:30 SD_WS SD_WS_51_TH_1 T: 6.1 H: 76
2017-03-23 00:02:30 SD_WS SD_WS_51_TH_1 temperature: 6.1
2017-03-23 00:02:30 SD_WS SD_WS_51_TH_1 humidity: 76
2017-03-23 00:02:30 SD_WS SD_WS_51_TH_1 battery: ok
2017-03-23 00:02:30 SD_WS SD_WS_51_TH_1 channel: 1
2017-03-23 00:02:30 SD_WS SD_WS_51_TH_1 trend: rising

Aber müssten da nicht noch weitere Sensoren erscheinen oder handelt es sich hier um den Lidl Sensor?

[sash.sc]

Hey Sidey.

Danke das du die revolt funkmessdosen eingebunden hast.
Seit dem habe ich am Tag mehrere Peaks in der Leistungsmessung drin.
Die Peaks gehen bis auf 3KW hoch.

Kannst du dir da einen Reim drauf machen?

Auch die Spannung bricht mit ein oder 2 Peaks ein.

Lauf Commandref kann man mit

Code Auswählen Erweitern

WhiteListID #45

das Protokoll 45 abschalten ?


Gruß Sascha

Gesendet von meinem SM-T560 mit Tapatalk

[mahowi]

Hallo Sidey,

kann es sein, daß mit Deinem Update-Skript etwas nicht stimmt. Ich habe den devr33-Zweig in meiner Update-Liste und seit gestern fällt mir auf, daß beim Update alle Module und Firmwares neu runtergeladen werden:

Code Auswählen Erweitern

signalduino
List of new / modified files since last update:
UPD ./FHEM/90_SIGNALduino_un.pm
UPD ./FHEM/98_Dooya.pm
UPD ./FHEM/14_SD_WS_Maverick.pm
UPD ./FHEM/14_Hideki.pm
UPD ./FHEM/firmware/SIGNALduino_nano328.hex
UPD ./FHEM/firmware/SIGNALduino_promini328.hex
UPD ./FHEM/firmware/SIGNALduino_uno.hex
UPD ./FHEM/firmware/SIGNALduino_nanoCC1101.hex
UPD ./FHEM/firmware/SIGNALDuino_radinoCC1101.hex
UPD ./FHEM/14_FLAMINGO.pm
UPD ./FHEM/14_SD_WS07.pm
UPD ./FHEM/14_SD_WS09.pm
UPD ./FHEM/14_SD_AS.pm
UPD ./FHEM/14_BresserTemeo.pm
UPD ./FHEM/41_OREGON.pm
UPD ./FHEM/14_SD_UT.pm
UPD ./FHEM/14_SIGNALduino_RSL.pm
UPD ./FHEM/14_SD_WS.pm
UPD ./FHEM/00_SIGNALduino.pm

Laut git haben sich aber nur 00_SIGNALduino.pm und 14_SD_WS.pm geändert. Das stört jetzt nicht wirklich, aber gerade bei der Firmware ist das schon öfter passiert. Das irritiert dann etwas, weil ich denke, es gibt eine neue Firmware, und nach dem Flashen ändert sich natürlich die Version nicht.

[sash.sc]

Hängt damit zusammen dass das normale update erst durchläuft und die Dateien alle ersetzt. Dann kommt das Update aus dem dev33r zum tragen. Da diese ja kurz vorher durch das reguläre Update in den original Zustand gebracht wurden, unterscheiden sich diese von der dev33r Version und es wird alles runter geladen.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[RappaSan]

attr global exclude_from_update (welche Module auch immer man exkludieren möchte)
z.B.
attr global exclude_from_update 41_OREGON.pm 00_SIGNALduino.pm 14_SD_WS07.pm 14_SD_WS09.pm 14_Hideki.pm 90_SIGNALduino_un.pm SIGNALduino_nano328.hex

[mahowi]

@sash.sc: Klar, aber es gab in FHEM ja keine Updates zu den Modulen.

@RappaSan: Ich weiß.    Ich will aber ja nix vom Update ausschließen.

Ich wollte ja nur darauf hinweisen. Ist halt einfach ein "Schönheitsfehler" und kein Problem. Es ging nur darum, daß es Updates zu nicht geänderten Dateien gibt.

[pejonp]

@mahowi

Doch es gab gestern updates zu einigen Dateien im dev-r33.
Pejonp

[mahowi]

Laut git haben sich aber nur 00_SIGNALduino.pm und 14_SD_WS.pm geändert.

14_SD_WS09.pm ist auch noch geändert worden. Aber wie schon gesagt, ich wollte das nur mal anmerken.

[Sidey]

Die Peaks gehen bis auf 3KW hoch.
Kannst du dir da einen Reim drauf machen?

Ich nehme an, Du denkst, es handelt sich um eine fehlerhafte Auswertung?
Habe ich spontan erst mal keine Idee. Hast Du mal die kompletten Logeinträge dazu?

Lauf Commandref kann man mit

Code Auswählen Erweitern

WhiteListID #45
das Protokoll 45 abschalten ?

Da habe ich jetzt gerade auch gestaunt, die Option kannte ich selbst noch nicht.
Abschalten kannst Du damit aber keine Protokolle, sondern nur das Attribut Whitelistid komplett deaktiveren.
Eine "blacklist" war schon mehrfach in Diskussion aber bislang gab es dazu keinen Anwendungsfall, der sich nicht mit der WhitelistID lösen lässt.

[Sidey]

14_SD_WS09.pm ist auch noch geändert worden. Aber wie schon gesagt, ich wollte das nur mal anmerken.

Wie genau machst Du denn ein Update? Kannst Du uns den exakten Befehl verraten?

Grüße Sidey