Signalduino Entwicklung

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

Vorheriges Thema - Nächstes Thema

Sidey

Zitat von: Lothar64 am 21 März 2016, 21:39:30
Wie man sieht wird der float Zustand genau anders rum gesendet, erst der breite Puls, dann der kurze. Das entspricht nicht der Beschreibung in dem PT2262 Datenblatt. Kann man das in der Signalduino.pm nicht auch als gültigen Puls "drehen", damit die anderen Module den Puls als float erkennen und verarbeiten können?
Die Module senden auch eine Pulsfolge, die 46ms lang ist. Ist die Beschränkung auf 31ms in dem Signalduino nötig? Ich habe das mal auf 62ms erhöht und kann dann noch weitere Sensoren sehen.

Hi Lothar,

1. Den Teil mit dem float habe ich noch nicht ganz verstanden. So ein Sender überträgt immer bits, dafür gibt es zum Glück nur zwei mögliche Zustände: 0 oder 1.
Ich nehme an, dem IT Modul gefallen die übergebenen Bits nicht, korrekt?

2. Was hast Du da denn geändert, damit 62ms ausgewertet werden können?
Bislang nehme ich noch an, dass ein Sensor zum einen das Frequenzband schont und zum anderen auch seine Batterie. Von daher, wird wohl kaum ein Sensor einen Pegel länger als 30ms halten.
Als low Pegel funktioniert das auch nicht, da dann der AGC vom Empfänger schon wieder einsetzt, kann also nur High sein und da kommt die Sache mit der Batterie / Sendezeit ins Spiel.
Welchen Zustand hat denn der 42ms Pegel? Low oder High? Wenn es Low ist, dann könnte es auch sehr gut eine Sendepause sein.

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

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

Ralf9

Zitat von: Sidey am 22 März 2016, 23:49:30
Bei -1 wird der Takt automatisch ermittelt.
Bei den vielen Steckdosen, gibt es leider keinen festen Takt.

Denkbar wäre auch noch eine Range von z.B. 160 - 300. Kann aber auch sein, dass es ein Gerät gibt, welches dann 400 benötigt usw.

Ok, beim IT v1 macht es dann wohl keinen Sinn.

Wie sieht es beim IT v3 aus? Da gibt es nicht so viele verschiedene Steckdosen die das v3 verwenden.
Falls keine v3 Steckdosen bekannt sind die einen Clock größer als 350 verwenden, dann könnte man ja bei der ID 17   
als clockabs z.B. 240 verwenden. Die 240 könnte man dann auch als default sendeclock nehmen.
Mit der defaulttoleranz von 0,3 würde die clockrange bis ca 312 gehen. Falls eine größere clocktoleranz notwendig ist, dann könnte man in der Protokollliste ein zusätzliches optionales Feld "clocktol" ergänzen.

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

Burny4600

So habe wieder ein wenig Zeit mich dem Problem der Oregon Sensoren zu wittmen.

Diese werden immer nur mehr schlecht als recht empfangen.
Update wurde heute auch schon ausgeführt.

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

Version V 3.2.0-b14 SIGNALduino - compiled at Mar 4 2016 22:13:07
cmds ?UseoneofViRtXFSPCG
config MS=1;MU=0;MC=1
ping OK
state opened


flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nano328
longids 0
verbose 1


Was kann ich Euch liefern für die Optimierungen.
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 23 März 2016, 18:33:26
Version V 3.2.0-b14 SIGNALduino - compiled at Mar 4 2016 22:13:07t

Die V 3.2.0-b14 ist fehlerhaft, bitte flashe die  V 3.2.0-b12

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

Burny4600

OK Ralf.
Mache ich.

Ergänzend wäre die Einbindung der RSSI der Sensoren auch nicht schlecht wenn ich diese auswerten könnte.
Bei der Konfigurationssoftware des RFXTRX Sensors werden diese zumindest eingelesen und sind somit im Datenprotokoll enthalten.
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 23 März 2016, 18:43:36
Ergänzend wäre die Einbindung der RSSI der Sensoren auch nicht schlecht wenn ich diese auswerten könnte.
Bei der Konfigurationssoftware des RFXTRX Sensors werden diese zumindest eingelesen und sind somit im Datenprotokoll enthalten.

Ja, das mit dem RSSI wünsche ich mir auch. Das ist was für die Wunschliste für das zukünftige Release 3.3.
So wie ich das sehe, dürfte das RSSI vom Empfänger des RFXTRX gemessen und dann in das Datenprotokoll eingefügt werden.
In der Oregon Protokollbeschreibung habe ich nichts über das RSSI gefunden.

Bei diesem Empfänger
http://www.ebay.de/itm/RXB6-433Mhz-Superheterodyne-Wireless-Receiver-Module-for-Arduino-ARM-AVR-/401047720475
steht in der Beschreibung:
has an analog RSSI signal strength level output

Hat jemand von diesem Superheterodyne Empfänger ein Datenblatt gefunden?

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

Lothar64

Hallo Sidey,
sorry da habe ich mich wohl nicht klar genug ausgedrückt.
Zu 1. Der Tristatezustand wird hier duch 2 Bits dargestellt.
Die 12 Zustände des itv1 Protokolls werden hier in der Ausgabe duch 24 Bits dargestellt:

sduino: postdemodulation value 0 0 1 1 0 0 1 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 1 1

Im IT.pm Modul steht wie die Bits dann weiter Verarbeitet werden:

my %bintotristate=(
  "00" => "0",
  "01" => "F",
  "11" => "1"
);

Die Bitkombination "10" ist dann der "unknown tristate" da er in dem itv1 Protokoll eine nicht gültige Kombination ist. Die Message wird dann verworfen.
Da die gesamte Message also nicht itv1 konform ist sollte man sie nicht an das IT Modul übergeben, sondern eine eigene ID zuweisen, die dann z.B. im Signalduino_un.pm Modul weiter ausgewertet werden kann.
Im IT.pm Modul wird die Gültigkeit der Message folgendermaßen überprüft:

    while (length($bin)>=2) {
      if (length($msg) == 7) {
        if (substr($bin,0,2) != "10") {
          $msgcode=$msgcode.$bintotristate{substr($bin,0,2)};
        } else {
          Log3 undef,4,"unknown tristate in \"$bin\"";
          return "unknown tristate in \"$bin\""
        }
      } elsif (length($msg) == 20 && (substr($msg, 1, 1)) eq 'h') { # HomeEasy EU
        $msgcode=$msgcode.$bintotristateHE{substr($bin,0,2)};
      } else {
        $msgcode=$msgcode.$bintotristateV3{substr($bin,0,2)};
      }
      $bin=substr($bin,2,length($bin)-2);
    }

Im It.pm Modul wird geprüft, ob die Message Länge 7 ist. Wenn ja ist es das itv1 Protokoll. Dann wird die Bitkombinationen auf Gültigkeit geprüft.
Wenn man diesen Check auch in Signalduino.pm einfügen könnte, werden nur noch gültige itv1 Messages an das it.pm Modul übergeben, anderenfalls kann man eine andere interne Signalduino id vergeben, die dann in Signalduino_un.pm weiter ausgewertet werden kann.

zu 2.
Dazu habe testhalber in der RF_Receiver setup() Funktion den Timerinit auf 63 erhöht.

Timer1.initialize(63*1000);

und in SignalDecoder.h das define geändert

#define maxPulse 62001  // Magic Pulse Length

Das ganze war nur ein Versuch! Ob ich alles richtig gemacht habe glaube ich nicht, ist auch egal, da es nur ein Veruch war, die Signale zu empfangen.
Die ganze Message, das Sync Signal und die 12 trisate Zustände ware 46ms lang, nicht ein einzelner Puls. Die Türkontakte sind in der Konfiguration geliefert worden. Man kann über Jumper die gesamte Signallänge unter 30ms gestellt bekommen. Das habe ich mal gemacht, ob die Zentrale das Signal dann noch erkennt habe ich noch nicht geprüft. Ich bin dazu noch nicht gekommen, habe leider zur Zeit sehr wenig Zeit.
Gruß
Lothar

Sidey

#1282
Zitat von: Burny4600 am 23 März 2016, 18:33:26
So habe wieder ein wenig Zeit mich dem Problem der Oregon Sensoren zu wittmen.
...
Was kann ich Euch liefern für die Optimierungen.

Hi,

ich bin an dem Problem dran. Habe ein paar Stellen im code angepasst. Bei mir läuft die MC Erkennung aktuell sehr gut mit den Anpassungen. Ich schätze ich habe da etwas gefunden.
Die neue Firmware habe ich in dev32 geladen.



Zitat von: Ralf9 am 23 März 2016, 19:37:49
Bei diesem Empfänger

http://www.ebay.de/itm/RXB6-433Mhz-Superheterodyne-Wireless-Receiver-Module-for-Arduino-ARM-AVR-/401047720475
steht in der Beschreibung:
has an analog RSSI signal strength level output

RSSI ist nicht im Protokoll selbst verankert, es wird vom Empfänger gemessen.
Datenblatt habe ich keines, aber ich kann mir nur vorstellen, dass der RSSI Wert mit einer Spannung dargestellt wird. Also der Pin auf dem es liegen sollte müsste dann nur an einen analogen Eingang und dort ausgewertet werden.
Der DER Pin ist es jedenfalls nicht, das habe ich heraus gefunden.



Zitat von: Lothar64 am 23 März 2016, 22:03:05

Die Bitkombination "10" ist dann der "unknown tristate" da er in dem itv1 Protokoll eine nicht gültige Kombination ist. Die Message wird dann verworfen.
...
Wäre es nicht zielführender, dieses Protokoll auch im IT Modul ein zu bauen.
Den Rest deines Vorschlages habe ich verstanden. Die Grundidee ist halt, alles was gleich moduliert ist, auch an das gleiche Modul zu übergeben.
Es ist aber auch möglich, die Daten an ein anderes Modul zu übergeben, wenn das IT Modul nichts damit anfangen konnte.


Zitat von: Lothar64 am 23 März 2016, 22:03:05
zu 2.
Dazu habe testhalber in der RF_Receiver setup() Funktion den Timerinit auf 63 erhöht.

Timer1.initialize(63*1000);

Jetzt blinkt die LED nur langsamer und wenn nichts empfangen wird, dauert es etwas länger bis die Signaldaten an FHEM übergeben werden.
Das kannst Du wieder zurück drehen.

Zitat von: Lothar64 am 23 März 2016, 22:03:05
und in SignalDecoder.h das define geändert

#define maxPulse 62001  // Magic Pulse Length


Das nutzt dir nichts, die verwendete Variable kann maximal 32767 darstellen.

Zitat von: Lothar64 am 23 März 2016, 22:03:05
Das ganze war nur ein Versuch! Ob ich alles richtig gemacht habe glaube ich nicht, ist auch egal, da es nur ein Veruch war, die Signale zu empfangen.
Die ganze Message, das Sync Signal und die 12 trisate Zustände ware 46ms lang, nicht ein einzelner Puls.
Kein Problem. Ich würde sagen, das hat nicht den gewünschten Effekt. Mit maxPulse  hast Du nur angegeben, wie groß der maximal gemessene Puls denn sein kann.
Wie lang die Nachricht selbst ist, wird nur durch den verfügbaren Speicher + die Dauer der einzelen Pulse bestimmt. Begrenzt ist aber nur der Speicher und die maximale Dauer eines Pulses.
Du kannst hier wieder auf Standard gehen, deine Anpassungen sind nicht notwendig.

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

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

noxx

hallo

ich bekomme leider den arduino nicht geflasht

in der log sehe ich nur
2016.03.24 23:24:57 3: sduino device opened
2016.03.24 23:24:57 1: define: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00
2016.03.24 23:24:57 1: init: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00
2016.03.24 23:25:07 1: Cannot init /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00, ignoring it (sduino)

Sidey

Hi Noxx,

was passiert denn, wenn Du versuchst zu flashen?

Gruß Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

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

noxx

#1285
Nichts. Eieruhr dann ist fhem-GUI weg

LOG
avrdude: Version 6.1, compiled on Jul  7 2015 at 10:29:47
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"

         Using Port                    : /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you



LOG FHEM:
2016.03.25 07:44:51 1: Including fhem.cfg
2016.03.25 07:44:51 3: telnetPort: port 7072 opened
2016.03.25 07:44:51 3: WEB: port 8083 opened
2016.03.25 07:44:51 3: WEBphone: port 8084 opened
2016.03.25 07:44:51 3: WEBtablet: port 8085 opened
2016.03.25 07:44:51 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2016.03.25 07:44:51 3: sduino: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 6 7
2016.03.25 07:44:51 3: sduino: IDlist MU 16 20 21 24 26 27 28 29 30 31 34 36 37 39 5 8 9
2016.03.25 07:44:51 3: sduino: IDlist MC 10 11 12 18
2016.03.25 07:44:51 3: Opening sduino device /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00
2016.03.25 07:44:51 3: Setting sduino serial parameters to 57600,8,N,1
2016.03.25 07:44:51 3: sduino device opened
2016.03.25 07:44:51 1: define: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00@57600
2016.03.25 07:44:51 1: init: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00@57600
2016.03.25 07:45:01 1: Cannot init /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_7543535303535110A031-if00, ignoring it (sduino)
2016.03.25 07:45:01 3: sduino: setting Verbose to: 4
2016.03.25 07:45:01 1: Including ./log/fhem.save
2016.03.25 07:45:01 1: usb create starting
2016.03.25 07:45:01 3: Probing CUL device /dev/ttyAMA0
2016.03.25 07:45:01 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.03.25 07:45:01 1: usb create end
2016.03.25 07:45:01 0: Featurelevel: 5.7
2016.03.25 07:45:01 0: Server started with 11 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1579)


Ralf9

Zitat von: noxx am 25 März 2016, 06:59:52
Nichts. Eieruhr dann ist fhem-GUI weg

was bekommst Du bei
ls -l /dev/serial/by-id/

und was steht beim sduino unter internals DEF?


ich bekomme bei ls -l /dev/serial/by-id/
lrwxrwxrwx 1 root root 13 25. Mär 10:08 usb-FTDI_FT232R_USB_UART_A600G900-if00-port0 -> ../../ttyUSB0

bei DEF steht:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600G900-if00-port0@57600

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

Burny4600

#1287
Eigentlich müsste die RSSI Information im Datenprotokoll bei den Oregon Sensoren enthalten sein.

Zumindest wird die Siganlstärke in db von der RFXtrx433E eigenen Konfigurationssoftware in db mit den Senderinformationen ausgewertet.

EIn Problem was ich mit der b12 Firmware immer noch habe das die Oregon Sensoren nicht mit der gleichen Geräte Definition angelegt werden wie es der RFXtrx433E Empfänger macht.
Da hängt sich immer noch etwas drann.
ZB:
THGR810_e3_1   
WGR800_b0
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 25 März 2016, 10:19:27
Eigentlich müsste die RSSI Information im Datenprotokoll bei den Oregon Sensoren enthalten sein.

Überleg mal wie soll das funktionieren?
Die 433 MHz Sensoren haben kein bidirektionales Protokoll, sie können nur senden.
Nur ein Empfänger kann die RSSI  messen.


Zitat von: Burny4600 am 25 März 2016, 10:19:27
Da hängt sich immer noch etwas drann.
ZB:
THGR810_e3_1   
WGR800_b0

Wie werden diese beiden beim RFXtrx433E angelegt?


Hast zum Vergleich auch schon mal die neue b18 getestet, ob sich der Empfang damit spürbar verbessert?
version: V 3.2.0-b18 SIGNALduino - compiled at Mar 24 2016 00:05:46

@Sidey
kannst Du zukünftig eine neue Firmware auch in CHANGED eintragen?

Kann es sein, daß mit der b18 auch die Erkennung von MS-Nachrichten besser geworden ist?

Ich wünsche noch schöne Osterfeiertage

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

noxx

#1289
Zitat von: Ralf9 am 25 März 2016, 10:16:32
was bekommst Du bei
ls -l /dev/serial/by-id/

und was steht beim sduino unter internals DEF?


ich bekomme bei ls -l /dev/serial/by-id/
lrwxrwxrwx 1 root root 13 25. Mär 10:08 usb-FTDI_FT232R_USB_UART_A600G900-if00-port0 -> ../../ttyUSB0

bei DEF steht:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600G900-if00-port0@57600

Gruß Ralf

pi@raspberrypi:~ $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Mär 25 11:17 usb-Arduino__www.arduino.cc__0043_95432313138351316160-if00 -> ../../ttyACM0
pi@raspberrypi:~ $


Habe den PI nochmal neu aufgesetzt und FHEM frisch installiert.
FHEM läuft, aber sobald ich den UNO in die fhem.cfg schreibe, startet
die WEBGui nicht mehr

Zitat2016.03.25 11:33:19 1: Including ./log/fhem.save
2016.03.25 11:33:19 1: usb create starting
2016.03.25 11:33:19 3: Probing CUL device /dev/ttyAMA0
2016.03.25 11:33:19 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.03.25 11:33:19 1: usb create end
2016.03.25 11:33:19 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.03.25 11:33:19 0: Featurelevel: 5.7
2016.03.25 11:33:19 0: Server started with 10 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 931)
Undefined subroutine &main::asyncOutput called at ./FHEM/00_SIGNALduino.pm line 1559.
2016.03.25 11:35:55 1: Including fhem.cfg
2016.03.25 11:35:55 3: telnetPort: port 7072 opened
2016.03.25 11:35:55 3: WEB: port 8083 opened
2016.03.25 11:35:55 3: WEBphone: port 8084 opened
2016.03.25 11:35:55 3: WEBtablet: port 8085 opened
2016.03.25 11:35:55 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2016.03.25 11:35:55 1: Including ./log/fhem.save
2016.03.25 11:35:55 1: usb create starting
2016.03.25 11:35:56 3: Probing CUL device /dev/ttyACM0
2016.03.25 11:35:56 3: Probing TCM_ESP3 device /dev/ttyACM0
2016.03.25 11:35:56 3: Probing ZWDongle device /dev/ttyACM0
2016.03.25 11:35:56 3: Probing FRM device /dev/ttyACM0
2016.03.25 11:36:02 3: Probing CUL device /dev/ttyAMA0
2016.03.25 11:36:02 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.03.25 11:36:02 1: usb create end
2016.03.25 11:36:02 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.03.25 11:36:02 0: Featurelevel: 5.7
2016.03.25 11:36:02 0: Server started with 9 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1011)
2016.03.25 11:37:02 1: Including fhem.cfg
2016.03.25 11:37:02 3: telnetPort: port 7072 opened
2016.03.25 11:37:02 3: WEB: port 8083 opened
2016.03.25 11:37:02 3: WEBphone: port 8084 opened
2016.03.25 11:37:02 3: WEBtablet: port 8085 opened
2016.03.25 11:37:02 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2016.03.25 11:37:02 3: sduino: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 6 7
2016.03.25 11:37:02 3: sduino: IDlist MU 16 20 21 24 26 27 28 29 30 31 34 36 37 39 5 8 9
2016.03.25 11:37:02 3: sduino: IDlist MC 10 11 12 18
2016.03.25 11:37:02 3: Opening sduino device /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_95432313138351316160-if00
2016.03.25 11:37:02 3: Setting sduino serial parameters to 57600,8,N,1
2016.03.25 11:37:02 3: sduino device opened
2016.03.25 11:37:02 1: define: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_95432313138351316160-if00
2016.03.25 11:37:02 1: init: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_95432313138351316160-if00
2016.03.25 11:37:05 3: sduino: Firmwareversion: V 3.2.0-b12 SIGNALduino - compiled at Feb 13 2016 21:37:33

2016.03.25 11:37:05 1: Including ./log/fhem.save
Undefined subroutine &main::asyncOutput called at ./FHEM/00_SIGNALduino.pm line 1559.


Zitatattr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd none
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global
attr WEB editConfig 1

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create

define sduino SIGNALduino /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_95432313138351316160-if00