Signalduino Entwicklung

Begonnen von thoffma3, 05 Juli 2015, 23:01:00

Vorheriges Thema - Nächstes Thema

Jarnsen

Zitat von: Ralf9 am 22 April 2016, 13:29:37
anscheinend passt irgendwas nicht beim IOWrite. Normalerweise müsste über den ioname=sduino und dem iotype=SIGNALduino die "sub SIGNALduino_Write($$$)" in der 00_SIGNALduino.pm aufgerufen werden.

@Sidey
Hast Du eine Idee an was es liegen könnte, daß das IOWrite nicht funktioniert?

Gruß Ralf

bin mir nicht sicher ob es mit Umstellung auf b22 kahm oder durch das FHEM update was ich danach direkt ausgeführt habe... vorher mit b21 ging es noch da hatte ich aber auch noch kein FHEM - Update gemacht...

Jarnsen
1 x RPi2,
1 x nanoCUL433, 1 x nanoCUL868, 1 x SIGNALduino433
Sonos/SonosSpeak, Homebridge, 2 x Enigma2, 10 x Nobily Rollläden, 3 x Intertechno Steckdosen
Pushover, Abfallerinnerung, MySensors, 7 x Max!

Ralf9

Zitat von: Jarnsen am 22 April 2016, 13:48:14
oder durch das FHEM update was ich danach direkt ausgeführt habe... vorher mit b21 ging es noch da hatte ich aber auch noch kein FHEM - Update gemacht...
ok, das ist mal ein Ansatz. Ich werde heute Abend bei meinem Testsystem auch mal das fhem updaten und dann beim dooya ein set versuchen.

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 tippe mal, Du hast das Fhem Update gemacht, nachdem du auf dev-r32 geupdated hast...

Schau einfach mal nach, welche Revision von 00_SignalDuino. PM bei dir läuft.

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

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

Jarnsen

Jup... Ok verstanden... Nochmal dev-32 drüber schieben...

Denkfehler


Gruß Jarnsen


Gesendet von iPhone mit Tapatalk
1 x RPi2,
1 x nanoCUL433, 1 x nanoCUL868, 1 x SIGNALduino433
Sonos/SonosSpeak, Homebridge, 2 x Enigma2, 10 x Nobily Rollläden, 3 x Intertechno Steckdosen
Pushover, Abfallerinnerung, MySensors, 7 x Max!

Jarnsen

Das wars...


Gesendet von iPhone mit Tapatalk
1 x RPi2,
1 x nanoCUL433, 1 x nanoCUL868, 1 x SIGNALduino433
Sonos/SonosSpeak, Homebridge, 2 x Enigma2, 10 x Nobily Rollläden, 3 x Intertechno Steckdosen
Pushover, Abfallerinnerung, MySensors, 7 x Max!

Ralf9

Zitat von: Burny4600 am 22 April 2016, 11:34:33
TS45  H0-WSMT-07 entspricht SD_WS07_T_1 und wird von nanoCUL433 mit nanoCUL433_DMSG = P7#5880A5F000 erkannt.
Damit sollte die Zuordnung ob es ein MU String ist festzustellen sein. Log wird noch erstellt.
Auch hier fehlt die Feuchte.

Mit dem log ist keine Zuordung der Nachrichen zu dem "TS45  H0-WSMT-07" möglich.
Bei der decodierten P7#5880A5F000 Nachricht kann ich nicht erkennen wo darin eine Feuchtigkeit enthalten sein soll.
Hier ist der Aufbau einer Protokoll 7 Nachricht:
  #     4    8  9    12            24    28       36
  # 00110110 1  010  000100000010  1111  00111000 0000  eas800z
  #     ID  Bat CHN       TEMP     ??   HUM



Es werden sehr viele unbekannte MU-Nachrichten empfangen die nicht decodiert werden können.


Zitat von: Burny4600 am 22 April 2016, 11:34:33
Die Oregon THGR810 Sensoren senden ca. alle 60Sec unabhängig ob sich die Temperatur oder Feuchte geändert hat.

Ich habe im log mal geschaut wie oft die Oregon Sensoren decodiert wurden:

Die THGR810_1 und  WGR800 werden sehr häufig fehlerfrei decodiert.
Bei dem THGR810_6 sieht es auch recht gut aus, er wurde ca 30 mal decodiert.

Die folgenden 3 sensoren wurden nicht oft erkannt:
2 mal THGR810_2
3 mal THWR800_3
8 mal PCR800

Bis auf ein paar wenige, bei denen bei der Nachricht 4 Bit fehlen, konnten alle erkannten Oregon Nachrichten decodiert werden.

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

RappaSan

#1551
Hab gerade gesehen: Signalduino hat nun 2 Versionen in einer.

Readings
Version V 3.2.0-b21 SIGNALduino - compiled at Apr 16 2016 01:44:24
...
version V 3.2.0-b22 SIGNALduino - compiled at Apr 18 2016 22:59:19
   
:)

Die neue dev-r32 Version läuft aber bei mir bis dato einwandfrei.

Burny4600

@Ralf
Zitat
Die THGR810_1 und  WGR800 werden sehr häufig fehlerfrei decodiert.
Was mich wundert ist das die Sensoren THWR800_3 und PCR800 nicht öfter erkannt werden. Diese senden ca. alle 60 Sec auch wenn sich am Sensor keine Änderungen ergeben haben. Der RFXtrx433E erkennt diese Sensoren ohne Probleme. Es wird der gleiche Antennentyp verwendet und der Standort der Antenne ist der gleiche.
Der THGR810_2 ist der gleiche Sensortyp wie der THGR810_6. Bei diesen beiden Sensortypen hat der RFXtrx433E Empfänger ebenfalls Probleme mit der Auswertung. Da der RFXtrx433E mit der Konfigurationssoftwäre aber tadellos die Sensoren empfängt, dürfte ein Problem in FHEM mit der Datenumwandlung auch für den RFXtrx433E vorhanden sein. Wobei die Anlage der Sensoren des Signalduino bei mir gar nicht mehr funktioniert.

ZitatMit dem log ist keine Zuordung der Nachrichen zu dem "TS45  H0-WSMT-07" möglich.
Wie kann ich hier noch etwas austesten?

ZitatEs werden sehr viele unbekannte MU-Nachrichten empfangen die nicht decodiert werden können.
Das könnte eventuell der FT007T oder TPX305 sein.
Welche Wiederholzeiten sind hier ersichtlich?
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Ralf9

Zitat von: Burny4600 am 24 April 2016, 12:00:19
@RalfWas mich wundert ist das die Sensoren THWR800_3 und PCR800 nicht öfter erkannt werden. Diese senden ca. alle 60 Sec auch wenn sich am Sensor keine Änderungen ergeben haben. Der RFXtrx433E erkennt diese Sensoren ohne Probleme. Es wird der gleiche Antennentyp verwendet und der Standort der Antenne ist der gleiche.
Der THGR810_2 ist der gleiche Sensortyp wie der THGR810_6. Bei diesen beiden Sensortypen hat der RFXtrx433E Empfänger ebenfalls Probleme mit der Auswertung. Da der RFXtrx433E mit der Konfigurationssoftwäre aber tadellos die Sensoren empfängt, dürfte ein Problem in FHEM mit der Datenumwandlung auch für den RFXtrx433E vorhanden sein.

Das Problem könnte evtl auch sein, daß die neueren v3 Sensoren ein abweichendes timing beim Manchester-Code haben. Das Problem wäre dann im Signalduino bzw RFXtrx433E


Zitat von: Burny4600 am 24 April 2016, 12:00:19
Wobei die Anlage der Sensoren des Signalduino bei mir gar nicht mehr funktioniert.

Ja, daß das Autocreate bei Dir nicht funktioniert ist mir in Deinem log auch schon aufgefallen.
Antwort #1520
https://forum.fhem.de/index.php/topic,38831.msg441769.html#msg441769
Es könnte evtl zu Konflikten kommen, wenn es die gleichen Sensorbezeichnungen schon beim RFXtrx433E gibt.

Zitat von: Burny4600 am 24 April 2016, 12:00:19
Wie kann ich hier noch etwas austesten?
Das könnte eventuell der FT007T oder TPX305 sein.
Welche Wiederholzeiten sind hier ersichtlich?

Um hier weiterzukommen, müsstest Du versuchen ob Du den 3 nicht erkannten Sensoren die raw-Nachrichten zuordnen kannst.

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: RappaSan am 24 April 2016, 11:31:30
Hab gerade gesehen: Signalduino hat nun 2 Versionen in einer.

Readings
Version V 3.2.0-b21 SIGNALduino - compiled at Apr 16 2016 01:44:24
...
version V 3.2.0-b22 SIGNALduino - compiled at Apr 18 2016 22:59:19

gib mal in der Eingabezeile folgendes ein, dann müsste es passen.
deletereading sduino Version

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: Ralf9 am 02 April 2016, 20:48:16
Ja, die angepasste IT.pm müsste auch mit dem Cul funktionieren.

Ich habe für den Signalduino auch das "set" geändert. Dies funktioniert aber z.Zt. nur mit der dev-32

Beim ITv1 wird für das senden jetzt auch das sendmsg verwendet. Das "set sduino ITclock" wird dadurch nicht mehr verwendet.
Beim  ITv1 und ITv3 kann jetzt im IT-Modul die ITclock gewählt werden. Wenn kein ITclock gewählt wird, wird als default 250 verwendet.

Kann mal jemand testen ob beim Signalduino und falls möglich auch beim cul das empfangen und senden vom ITv1 und ITv3 noch sauber funktioniert?

Gruß Ralf

Ich habe es heute selbst gestestet ob das angepasste IT-Modul auch mit dem Cul funktioniert. Ich habe mir dazu einen nanoCul wieder zusammengesteckt, den ich noch rumliegen hatte.
Ich habe mit dem nanoCul das senden von ITv1 und ITv3 getestet. Beim ITv1 konnte ich ein Intertechno Modul schalten. Beim ITv3 wurde die vom nanoCul gesendete Nachricht vom Signalduino erkannt und angezeigt.
Wichtig: Beim Cul scheint ein Fehler bei der ITrepetition zu sein. Wenn in dem IT-Modul ein Attribut ITrepetition definiert ist, dann funktioniert das senden nicht!

Das Empfangen von ITv1 funktioniert auch. Das Empfangen von ITv3 konnte ich nicht testen, da ich kein ITv3 Sender habe.

Die Probleme beim senden mit dem Signalduino konnte ich nicht nachvollziehen. Sidey hat das Senden mit dem angepassten IT-Modul und dem Signalduino auch erfolgreich getestet.

Hier ist die aktuelle Version von meinen anpassungen an dem IT-Modul:
update all https://raw.githubusercontent.com/Ralf9/test/master/controls_signalduino.txt

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

Stellst Du die Änderungen noch als Patch bereit, damit Björn es in die Standard Version einchecken kann?
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

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

Sidey

Zitat von: Burny4600 am 22 April 2016, 12:53:48
Anbei das Log betreffend der fehlerhaft ausgewerteten Sensoren.


Die zwei Nachrichten, könnten eventuell eine Übertragung eines Sensors sein, der nicht "richtig" empfangen wurde.

Die 1. MU Nachricht, passt ganz gut zum OSV3 preamble Teil.

Danach kommt eine MC Nachricht, die vom Takt zu OSV3 passt.
2016.04.22 12:50:59 4: sduino/msg READ: MU;P0=-114;P1=92;P2=324;P3=-658;D=0102323232323232323232323232323232323232323;CP=2;
2016.04.22 12:50:59 4: sduino/msg READ: MC;LL=-1048;LH=905;SL=-554;SH=474;D=EB122401A160738090124A4;C=459;L=91;

Ich habe aber keine Idee, warum es zwischendrin zu einer Ausgabe der MU Nachricht kam.

Hier ist noch so was, da fehlt die Preamble komplett:

2016.04.22 12:51:32 4: sduino/msg READ: MC;LL=-1020;LH=936;SL=-508;SH=469;D=5183011F4293C3FFA8C1808FA149E1FFD460C04;C=468;L=156;


Ist es möglich, einen der Empfänger, die nicht funktionieren und den SIGNALduino irgendwie vom Rest abzuschotten, damit nur noch die Nachrichten empfangen werden, welche nicht funktionieren?

Ich habe leider keine andere Idee, wie man den Fehler finden sollte. Es muss schon recht speziell sein.


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

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

Burny4600

@Sidey & @Ralf9

Ich weis wirklich nicht  mehr was ich machen kann, ich habe den kompleten Antennenanschluß entfernt an dem verwendeten Empfänger und cih profisorisch alles abgeschirmt, aber der Empfänger nimmt immer noch sehr viele andere Sensoren auf.

Eigentlich sollte es nur der THGR810_6 sein.
Ich hoffe ihr findet dennoch etwas heraus aus dem Log.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Ralf9

#1559
Zitat von: Burny4600 am 25 April 2016, 10:44:35
@Sidey & @Ralf9

Ich weis wirklich nicht  mehr was ich machen kann, ich habe den kompleten Antennenanschluß entfernt an dem verwendeten Empfänger und cih profisorisch alles abgeschirmt, aber der Empfänger nimmt immer noch sehr viele andere Sensoren auf.

Eigentlich sollte es nur der THGR810_6 sein.
Ich hoffe ihr findet dennoch etwas heraus aus dem Log.

In dem log hat es einige fehlerhafte Nachrichten. @Sidey, kannst Du damit was anfangen?

Ich finde die Häufigkeit, die der THGR810_6 empfangen wird ist inzwischen einigermaßen brauchbar.
In einem der letzten logs ist mir aufgefallen, daß der THGR810_2 und THWR800_3 noch zu selten empfangen wird.
Der PCR800 könnte auch noch etwas häufiger empfangen werden.

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