Ich habe bisher relativ problemlos ein FHEM-Setup auf einem Raspberry Pi betrieben, um einige MAX!-Komponenten zu steuern und zu überwachen. Bisher wurde der MAX! Cube genutzt, um per WLAN die Daten auszulesen und auf dem Raspberry Pi auszuwerten.
Da der Cube aber in unregelmäßigen Abständen alle angelernten Geräte vergisst und ich die USB-Ports des Raspberry Pis für andere Dinge benötige, statt eines CULs von Busware das SCC Modul verwenden, um die Daten direkt über das Modul aus den MAX!-Komponenten auszulesen.
Leider gibt es dabei einige Probleme ... Vielleicht kann ja jemand weiterhelfen.
Nach einigen Anfangsschwierigkeiten wegen der doch recht mageren Dokumentation in diesem Bereich habe ich das SCC Modul endlich zum Laufen bekommen.
- GPIO17 und GPIO18 konfiguriert
- /boot/cmdline.txt und /etc/inittab bearbeitet
- neu gestartet
- FHEM konfiguriert:
define SCC CUL /dev/ttyAMA0@38400 1234
attr SCC rfmode MAX
attr SCC room [Steuerung]
set SCC led 01
define SCCMAX CUL_MAX 123456
attr SCCMAX IODev SCC
attr SCCMAX room [Steuerung]
define FileLog_SCCMAX FileLog ./log/%Y-%m-SCCMAX.log SCCMAX
attr FileLog_SCCMAX logtype text
attr FileLog_SCCMAX room [Steuerung]
- FHEM per "set SCCMAX pairmode 120" in den Pairing-Modus versetzt
- einen Fensterkontakt und ein Heizkörperthermostat angelernt
- über Nacht das System laufen lassen
Heute morgen sind mir dann ein paar Dinge aufgefallen...
Die Logdatei 2014-11-SCCMAX.log enthält folgende Einträge:
2014-11-07_22:40:13 SCCMAX pairmode 120
2014-11-07_22:45:42 SCCMAX pairmode 120
2014-11-08_00:23:31 SCCMAX packetsLost: 1
2014-11-08_00:59:47 SCCMAX packetsLost: 2
2014-11-08_01:59:47 SCCMAX packetsLost: 3
2014-11-08_03:59:47 SCCMAX packetsLost: 4
2014-11-08_04:59:48 SCCMAX packetsLost: 5
2014-11-08_05:59:48 SCCMAX packetsLost: 6
2014-11-08_06:59:48 SCCMAX packetsLost: 7
2014-11-08_07:59:48 SCCMAX packetsLost: 8
2014-11-08_09:59:48 SCCMAX packetsLost: 9
2014-11-08_10:59:48 SCCMAX packetsLost: 10
2014-11-08_11:59:48 SCCMAX packetsLost: 11
2014-11-08_12:09:19 SCCMAX packetsLost: 12
2014-11-08_12:18:35 SCCMAX packetsLost: 13
2014-11-08_12:25:53 SCCMAX packetsLost: 14
2014-11-08_13:25:53 SCCMAX packetsLost: 15
2014-11-08_14:25:53 SCCMAX packetsLost: 16
Soweit nicht weiter schlimm. 16 lost packets in 16 Stunden, damit könnte ich leben.
Über Nacht hat das System durch autolearn alle weiteren Geräte hier im Haus kennengelernt. Diese sind momentan noch mit dem Raspberry Pi und dem Cube verbunden, während meine Entwicklung mit dem SCC Modul auf einem zweiten Pi stattfindet.
Nun passiert folgendes:
Die Logdateien zu den ganzen Geräten zeigen keinerlei Regelmäßigkeit in Sachen Updates. Einige Logfiles zeigen, dass Geräte alle 3 Minuten abgefragt werden, andere jede Stunde, oder alle 10 Minuten, alle 1 Stunde 15 Minuten ... völlig wahllose das ganze.
Am schlimmsten aber ist folgendes:
2014-11-07_22:45:45 MAX_0607d0 firmware: 1.6
2014-11-07_22:45:45 MAX_0607d0 testresult: 255
2014-11-07_22:45:46 MAX_0607d0 ecoTemperature: 17.0
2014-11-07_22:45:46 MAX_0607d0 comfortTemperature: 21.0
2014-11-07_22:45:46 MAX_0607d0 maximumTemperature: on
2014-11-07_22:45:46 MAX_0607d0 minimumTemperature: off
2014-11-07_22:45:46 MAX_0607d0 boostValveposition: 80
2014-11-07_22:45:46 MAX_0607d0 boostDuration: 25
2014-11-07_22:45:46 MAX_0607d0 measurementOffset: 0.0
2014-11-07_22:45:46 MAX_0607d0 windowOpenTemperature: 12.0
2014-11-07_22:45:46 MAX_0607d0 windowOpenDuration: 15
2014-11-07_22:45:46 MAX_0607d0 maxValveSetting: 100
2014-11-07_22:45:46 MAX_0607d0 valveOffset: 0
2014-11-07_22:45:46 MAX_0607d0 decalcification: Sat 12:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-0-Sat-time: 00:00-06:00 / 06:00-22:00 / 22:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-0-Sat-temp: 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 weekprofile-1-Sun-time: 00:00-06:00 / 06:00-22:00 / 22:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-1-Sun-temp: 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 weekprofile-2-Mon-time: 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-2-Mon-temp: 17.0°C / 21.0°C / 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 weekprofile-3-Tue-time: 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-3-Tue-temp: 17.0°C / 21.0°C / 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 weekprofile-4-Wed-time: 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-4-Wed-temp: 17.0°C / 21.0°C / 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 weekprofile-5-Thu-time: 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-5-Thu-temp: 17.0°C / 21.0°C / 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 weekprofile-6-Fri-time: 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2014-11-07_22:45:46 MAX_0607d0 weekprofile-6-Fri-temp: 17.0°C / 21.0°C / 17.0°C / 21.0°C / 17.0°C
2014-11-07_22:45:46 MAX_0607d0 waiting for data
2014-11-07_22:45:47 MAX_0607d0 mode: manual
2014-11-07_22:45:47 MAX_0607d0 battery: ok
2014-11-07_22:45:47 MAX_0607d0 desiredTemperature: 20.0
2014-11-07_22:45:47 MAX_0607d0 valveposition: 9
2014-11-07_22:45:47 MAX_0607d0 20.0°C
2014-11-07_22:45:55 MAX_0607d0 mode: manual
2014-11-07_22:45:55 MAX_0607d0 battery: ok
2014-11-07_22:45:55 MAX_0607d0 desiredTemperature: 20.0
2014-11-07_22:45:55 MAX_0607d0 valveposition: 9
2014-11-07_22:45:55 MAX_0607d0 20.0°C
2014-11-07_22:46:29 MAX_0607d0 mode: manual
2014-11-07_22:46:29 MAX_0607d0 battery: ok
2014-11-07_22:46:29 MAX_0607d0 desiredTemperature: 20.0
2014-11-07_22:46:29 MAX_0607d0 temperature: 20.4
2014-11-07_22:46:29 MAX_0607d0 valveposition: 9
2014-11-07_22:46:29 MAX_0607d0 20.0°C
2014-11-07_22:49:35 MAX_0607d0 TimeInformationHour: 1
2014-11-07_23:04:29 MAX_0607d0 mode: manual
2014-11-07_23:04:29 MAX_0607d0 battery: ok
2014-11-07_23:04:29 MAX_0607d0 desiredTemperature: 14.5
2014-11-07_23:04:29 MAX_0607d0 temperature: 20.1
2014-11-07_23:04:29 MAX_0607d0 valveposition: 9
2014-11-07_23:04:29 MAX_0607d0 14.5°C
2014-11-07_23:06:29 MAX_0607d0 mode: manual
2014-11-07_23:06:29 MAX_0607d0 battery: ok
2014-11-07_23:06:29 MAX_0607d0 desiredTemperature: 21.0
2014-11-07_23:06:29 MAX_0607d0 temperature: 20.0
2014-11-07_23:06:29 MAX_0607d0 valveposition: 60
2014-11-07_23:06:29 MAX_0607d0 21.0°C
Das war das Log, bevor ich es umbenannt habe.
2014-11-08_02:59:25 Schlafzimmer_Heizung mode: manual
2014-11-08_02:59:25 Schlafzimmer_Heizung battery: ok
2014-11-08_02:59:25 Schlafzimmer_Heizung desiredTemperature: 21.0
2014-11-08_02:59:25 Schlafzimmer_Heizung valveposition: 60
2014-11-08_06:18:29 Schlafzimmer_Heizung mode: manual
2014-11-08_06:18:29 Schlafzimmer_Heizung battery: ok
2014-11-08_06:18:29 Schlafzimmer_Heizung desiredTemperature: 21.0
2014-11-08_06:18:29 Schlafzimmer_Heizung temperature: 19.4
2014-11-08_06:18:29 Schlafzimmer_Heizung valveposition: 68
2014-11-08_08:59:26 Schlafzimmer_Heizung mode: manual
2014-11-08_08:59:26 Schlafzimmer_Heizung battery: ok
2014-11-08_08:59:26 Schlafzimmer_Heizung desiredTemperature: 21.0
2014-11-08_08:59:26 Schlafzimmer_Heizung valveposition: 68
2014-11-08_12:14:29 Schlafzimmer_Heizung mode: manual
2014-11-08_12:14:29 Schlafzimmer_Heizung battery: ok
2014-11-08_12:14:29 Schlafzimmer_Heizung desiredTemperature: 21.0
2014-11-08_12:14:29 Schlafzimmer_Heizung temperature: 21.2
2014-11-08_12:14:29 Schlafzimmer_Heizung valveposition: 75
Und dies ist das Logfile, nachdem ich es umbenannt habe. Wie man klar sehen kann, werden die Daten quasi überhaupt nicht ausgelesen. Bzw. nur sehr sehr sehr sporadisch. Damit ist eine effektive Heizungssteuerung, die bei mir auch die Gastherme an und ab schaltet, nicht möglich...
Kann mir jemand vielleicht sagen, wie ich dafür sorgen kann, dass die Daten zuverlässlicher, in geregelten Abständen (alle 300 Sekunden, wie beim Cube ("define Cube MAXLAN 192.168.121.30:62910 300 ondemand")) ausgelesen werden können?
Nach ein bischen rumprobieren scheint es mir so, als ob das SCC Modul kein Polling macht, sondern die MAX!-Komponenten lediglich bei Statusänderungen diese per Funk durch die Gegend schicken und das SCC Modul diese nur aufnimmt.
Ist es möglich das SCC Modul zum Polling zu bewegen?
Oder muss ich mir einen Timer bauen, der alle Geräte in regelmäßigen Abständen einen Befehl schickt (Thermostate auf auto setzen z.B.), damit diese ein Statusupdate schicken?
Hallo kheldorn
du hast alles richtig erkannt.
Mit dem Max-Temperatur-Scanner eine Lösung.
http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner (http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner)
John
Interessant. Hatte ich bei meiner Suche nicht gefunden gehabt... Ich schau's mir mal an. Danke erstmal.
Hatte mir erstmal einen kleinen Trick einfallen lassen, der zumindest für die Heizungsthermostate, aber nicht für die Fenstersensoren funktioniert:
define Update_ThermostatData at +*00:05:00 { \
fhem("set Schlafzimmer_Heizung wakeUp 1");; \
fhem("set Kueche_Heizung wakeUp 1");; \
}
attr Update_ThermostatData group _Heizung
attr Update_ThermostatData room hidden
Beachtet natürlich die dutycycles usw. nicht, aber besser als gar nichts....
Das wakeUp liefert nicht die Temperatur, die das Thermostat misst.
Zitat2014-11-08 22:23:36 MAX HT.JOHN wakeUp
2014-11-08 22:23:37 MAX HT.JOHN mode: auto
2014-11-08 22:23:37 MAX HT.JOHN battery: ok
2014-11-08 22:23:37 MAX HT.JOHN desiredTemperature: 19.0
2014-11-08 22:23:37 MAX HT.JOHN valveposition: 7
2014-11-08 22:23:37 MAX HT.JOHN 19.0 °C
2014-11-08 22:23:37 MAX HT.JOHN 19.0 °C
Der Fensterkontakt meldet sich 1x/Stunde.
John
Guter Einwand.
Hab den Scanner inzwischen eingebunden und augenscheinlich scheint es zumindest im Moment, mit nur einem Thermostaten, zu funktionieren.
Danke nochmal.
Zu früh gereut, würde ich mal sagen ...
Nachdem der Scanner bis in die Nacht hinein problemlos funktioniert hat und etwa alle 6 Minuten die Werte des Thermostaten geliefert hat, war plötzlich schluss.
2014-11-09_01:46:12 Schlafzimmer_Heizung desiredTemperature auto 19.0
2014-11-09_01:46:14 Schlafzimmer_Heizung mode: auto
2014-11-09_01:46:14 Schlafzimmer_Heizung battery: ok
2014-11-09_01:46:14 Schlafzimmer_Heizung desiredTemperature: 19.0
2014-11-09_01:46:14 Schlafzimmer_Heizung valveposition: 17
2014-11-09_01:46:29 Schlafzimmer_Heizung mode: auto
2014-11-09_01:46:29 Schlafzimmer_Heizung battery: ok
2014-11-09_01:46:29 Schlafzimmer_Heizung desiredTemperature: 19.0
2014-11-09_01:46:29 Schlafzimmer_Heizung temperature: 19.8
2014-11-09_01:46:29 Schlafzimmer_Heizung valveposition: 17
2014-11-09_01:52:12 Schlafzimmer_Heizung desiredTemperature 19.0
2014-11-09_01:52:13 Schlafzimmer_Heizung mode: manual
2014-11-09_01:52:13 Schlafzimmer_Heizung battery: ok
2014-11-09_01:52:13 Schlafzimmer_Heizung desiredTemperature: 19.0
2014-11-09_01:52:13 Schlafzimmer_Heizung valveposition: 17
2014-11-09_01:52:29 Schlafzimmer_Heizung mode: manual
2014-11-09_01:52:29 Schlafzimmer_Heizung battery: ok
2014-11-09_01:52:29 Schlafzimmer_Heizung desiredTemperature: 19.0
2014-11-09_01:52:29 Schlafzimmer_Heizung temperature: 19.8
2014-11-09_01:52:29 Schlafzimmer_Heizung valveposition: 17
2014-11-09_01:55:12 Schlafzimmer_Heizung desiredTemperature auto 19.0
2014-11-09_07:34:12 Schlafzimmer_Heizung desiredTemperature auto
2014-11-09_13:55:12 Schlafzimmer_Heizung desiredTemperature auto 19.0
2014-11-09_13:55:13 Schlafzimmer_Heizung mode: auto
2014-11-09_13:55:13 Schlafzimmer_Heizung battery: ok
2014-11-09_13:55:13 Schlafzimmer_Heizung desiredTemperature: 19.0
2014-11-09_13:55:13 Schlafzimmer_Heizung valveposition: 0
2014-11-09_13:56:29 Schlafzimmer_Heizung mode: auto
2014-11-09_13:56:29 Schlafzimmer_Heizung battery: ok
2014-11-09_13:56:29 Schlafzimmer_Heizung desiredTemperature: 19.0
2014-11-09_13:56:29 Schlafzimmer_Heizung temperature: 21.4
2014-11-09_13:56:29 Schlafzimmer_Heizung valveposition: 0
Erst nach einem "shutdown restart" in FHEM bekomme ich nun wieder Werte.
Irgendwo um 01:55 Uhr herum habe ich Updates auf dem Pi installiert. Kann es sein, dass das SCC Modul/FHEM/whoever sich irgendwo verschluckt hat, weil der Update-Prozess zu viel CPU-Auslastung produziert hat?
Um solche Probleme zu verhindern starte ich den Pi immer schon automatisch um 0:58 Uhr neu ... hilft halt nur wenig, wenn es kurz danach kaputt geht. :(
Was spricht die Log-Datei ?
Mit verbose kannst die den Detaillierungs-Grad der Log-Ausgaben verändern. Je höher die Zahl, umso geschwätziger.
Dazu rate, sonst kann schwer diagnostizieren.
Ausserdem hast zu zu deiner Systemkonfiguration noch nichts gesagt. (Raspi, Fritzbox ...)
Wäre gut, wenn du das in der Signatur vermerkst, ich finde es mittlerweile lästig immer wieder dieselben Fragen stellen zu müssen.
John
So, nachdem ich heute Morgen/Mittag das FHEM neu gestartet hatte, lief es erstmal wieder. Vorhin ist es dann wohl wieder abgeschmiert.
Ich habe nun "verbose 5" eingestellt und auch das Logging etwas detailierter gestalltet, mal gucken, ob es wieder kaputt geht.
2014-11-09_19:12:29 Schlafzimmer_Heizung mode: auto
2014-11-09_19:12:29 Schlafzimmer_Heizung battery: ok
2014-11-09_19:12:29 Schlafzimmer_Heizung desiredTemperature: 20.5
2014-11-09_19:12:29 Schlafzimmer_Heizung temperature: 20.8
2014-11-09_19:12:29 Schlafzimmer_Heizung valveposition: 29
2014-11-09_19:14:18 Schlafzimmer_Heizung desiredTemperature 20.5
2014-11-09_21:21:12 Schlafzimmer_Heizung desiredTemperature 20.5
2014-11-09_21:21:13 Schlafzimmer_Heizung mode: manual
2014-11-09_21:21:13 Schlafzimmer_Heizung battery: ok
2014-11-09_21:21:13 Schlafzimmer_Heizung desiredTemperature: 20.5
2014-11-09_21:21:13 Schlafzimmer_Heizung valveposition: 39
Eben um 21:21 Uhr habe ich einfach die fhem.cfg nochmal gespeichert, woraufhin ich eine Fehlermeldung (die ich natürlich nicht kopiert habe) erhalten habe, dass ich irgendwas wegen dem watchShutter definieren sollte. Gleiche Meldung tauchte auch schon beim ersten Mal auf, als es kaputt ging. Sobald es wieder kaputt geht, werde ich die Meldung hier natürlich posten.
Meine fhem.cfg enthält folgende Definitionen:
define Schlafzimmer_Fenster MAX ShutterContact 05e849
attr Schlafzimmer_Fenster group Schlafzimmer
attr Schlafzimmer_Fenster room Haus
define Schlafzimmer_Heizung MAX HeatingThermostat 0607d0
attr Schlafzimmer_Heizung group Schlafzimmer
attr Schlafzimmer_Heizung room Haus
attr Schlafzimmer_Heizung scanTemp 1
attr Schlafzimmer_Heizung userReadings watchShutter { return "Schlafzimmer_Fenster";; }
p.s.: Ich hab nen Raspberry Pi Model B, Busware SCC Modul und momentan an diesem Pi 1 MAX!-Heizkörperthermostat und MAX!-Fenstersensor angeschlossen. Am Ende sollen es 6 Heizkörperthermostate, 4 Fenstersensoren und 1 Wandthermostat sein.
Und wieder ist es tot. Die Logdateien sind allerdings nicht sehr hilfreich (verbose 5).
Auf der Startseite von FHEM erscheint folgende Fehlermeldung:
Error messages while initializing FHEM:
statefile: Please define MAXSCAN.SHUTTER.EVENT first
Nach dem Speichern der fhem.cfg erscheint ebenfalls folgende Meldung:
Please define MAXSCAN.SHUTTER.EVENT first
Danach ist die Fehlermeldung von der Startseite verschwunden und auch nach dem erneuten Speichern der fhem.cfg taucht sie nicht mehr auf.
Kurz vorher hatte ich den Pi wegen einiger Updates neu gestartet:
Broadcast message from root@pi2 (pts/2) (Sun Nov 9 22:02:31 2014):
The system is going down for reboot NOW!
...
Last login: Sun Nov 9 22:03:09 2014
Seit dem nichts mehr im Log...
2014-11-09_21:58:12 Schlafzimmer_Heizung desiredTemperature 20.5
2014-11-09_21:58:13 Schlafzimmer_Heizung mode: manual
2014-11-09_21:58:13 Schlafzimmer_Heizung battery: ok
2014-11-09_21:58:13 Schlafzimmer_Heizung desiredTemperature: 20.5
2014-11-09_21:58:13 Schlafzimmer_Heizung valveposition: 39
2014-11-09_21:58:13 Schlafzimmer_Heizung 20.5 °C
2014-11-09_21:58:13 Schlafzimmer_Heizung watchShutter: Schlafzimmer_Fenster
2014-11-09_21:58:29 Schlafzimmer_Heizung mode: manual
2014-11-09_21:58:29 Schlafzimmer_Heizung battery: ok
2014-11-09_21:58:29 Schlafzimmer_Heizung desiredTemperature: 20.5
2014-11-09_21:58:29 Schlafzimmer_Heizung temperature: 20.5
2014-11-09_21:58:29 Schlafzimmer_Heizung valveposition: 39
2014-11-09_21:58:29 Schlafzimmer_Heizung 20.5 °C
2014-11-09_21:58:29 Schlafzimmer_Heizung watchShutter: Schlafzimmer_Fenster
2014-11-09_22:03:36 Schlafzimmer_Heizung desiredTemperature auto 20.5
Leider wurden auch nach dem Speichern der fhem.cfg keine Messwerte ins Log geschrieben. Nach einem "shutdown restart" in FHEM war die oben genannte Fehlermeldung wieder da.
Eine Abfrage des "credit10ms"-Wertes meines SCC Moduls ergibt "No answer". :( Gleiches gilt für den Wert "uptime". Irgendwas stimmt da also nicht... Denn es hat ja schon alles funktioniert...
Was ich außerdem kriege sind jede Menge Meldungen diesert Art, wobei sie offensichtlich (siehe Zeitstempel) nicht in direktem Zusammenhang mit den fehlenden Messwerten stehen:
2014-11-08_21:00:13 SCCMAX UNKNOWNCODE MAX,0,ThermostatState,05b2bf,18202800C4
2014-11-08_21:02:00 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:02:31 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:05:00 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:05:22 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:08:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:08:09 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:11:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:11:08 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:14:00 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:14:04 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:15:21 SCCMAX UNKNOWNCODE MAX,0,Ack,04b1e9,00
2014-11-08_21:16:56 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:17:00 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:19:45 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:20:00 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:22:30 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:23:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:25:27 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:26:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:28:21 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:29:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:29:27 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:29:27 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:32:02 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:33:58 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:35:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:36:57 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:38:01 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2bf,01182028
2014-11-08_21:39:52 SCCMAX UNKNOWNCODE MAX,0,Ack,05b2b8,0118132A
2014-11-08_21:40:36 SCCMAX UNKNOWNCODE MAX,0,Ack,04b1e9,00
Zu Klärung :
es gibt eine Event-Log (die immer wieder schickst)
und es gibt ein File-Log (Menüpunkt Logfile).
Verbose wirkt sich nur auf Letzteres aus.
Und mit verbose 5 wächst die mächtig an.
ZitatPlease define MAXSCAN.SHUTTER.EVENT first
Das ist normal und sollte kein Problem darstellen.
Der Scanner erzeugt den Event beim Starten jedesmal neu.
John
2014.11.09 23:08:36 5: Cmd: >define SCC CUL /dev/ttyAMA0@38400 1234<
2014.11.09 23:08:36 3: Opening SCC device /dev/ttyAMA0
2014.11.09 23:08:36 3: Setting SCC baudrate to 38400
2014.11.09 23:08:36 3: SCC device opened
2014.11.09 23:08:36 5: SW: V
2014.11.09 23:08:39 5: SW: V
2014.11.09 23:08:42 5: SW: V
2014.11.09 23:08:45 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
2014.11.09 23:08:45 5: Cmd: >attr SCC rfmode MAX<
2014.11.09 23:08:45 5: SW: X21
2014.11.09 23:08:45 5: SW: Zr
2014.11.09 23:08:45 2: Switched SCC rfmode to MAX
2014.11.09 23:08:45 5: Cmd: >attr SCC room [Steuerung]<
2014.11.09 23:08:45 5: Cmd: >define SCCMAX CUL_MAX 123456<
2014.11.09 23:08:45 1: PERL WARNING: Use of uninitialized value in numeric ge (>=) at ./FHEM/14_CUL_MAX.pm line 59, <$fh> line 57.
2014.11.09 23:08:45 1: PERL WARNING: Use of uninitialized value in numeric ge (>=) at ./FHEM/14_CUL_MAX.pm line 65, <$fh> line 57.
2014.11.09 23:08:45 5: Cmd: >attr SCCMAX IODev SCC<
2014.11.09 23:08:45 5: Cmd: >attr SCCMAX room [Steuerung]<
2014.11.09 23:08:45 5: Cmd: >setstate SCC opened<
2014.11.09 23:08:45 5: Cmd: >setstate SCC 2014-11-09 21:16:20 cmds m B C F i A Z G M Y R T V W X e f * l t u x<
2014.11.09 23:08:45 5: Cmd: >setstate SCC 2014-11-09 23:08:18 credit10ms No answer<
2014.11.09 23:08:45 5: Cmd: >setstate SCC 2014-11-09 22:02:18 state Initialized<
2014.11.09 23:08:45 5: Cmd: >setstate SCC 2014-11-09 23:00:35 uptime No answer<
2014.11.09 23:08:45 5: Cmd: >setstate SCCMAX Defined<
2014.11.09 23:08:45 5: Cmd: >setstate SCCMAX 2014-11-08 18:30:15 packetsLost 19<
Hast schon gesehen
Zitat2014.11.09 23:08:45 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
hochinteressant oder ?
Du musst erst die Basics klären bevor du dich mit den höheren Dingen beschäftigst.
Alle zuvor behandelten Fehler sind Folgefehler.
John
Die Frage ist nur, warum das passiert.
Inzwischen funktioniert es wieder ... wobei ich keine Ahnung habe, was ich dafür getan habe...
Was ich getan habe:
- sudo poweroff
- kurz gewartet, wieder eingeschaltet
Danach
pi@pi2 ~ $ cat /sys/class/gpio/gpio18/value
1
pi@pi2 ~ $ cat /sys/class/gpio/gpio17/value
1
pi@pi2 ~ $ sudo echo 0 > /sys/class/gpio/gpio17/value
pi@pi2 ~ $ sudo echo 1 > /sys/class/gpio/gpio17/value
All das sollte bei einem Neustart aber auch passieren.
Meine /etc/rc.local enthält folgendes:
# Init GPIOs
/usr/local/bin/init_gpio.sh
echo GPIOs are running > /tmp/gpio.log
exit 0
Die Datei /usr/local/bin/init_gpio.sh folgendes:
#!/bin/bash
# Init GPIOs
sudo insmod /home/pi/rpi_SoftPwm/pwm.ko
sudo echo 23 > /sys/class/soft_pwm/export
sudo chmod 666 /sys/class/soft_pwm/pwm-23/duty_cycle
sudo chmod 666 /sys/class/soft_pwm/pwm-23/frequency
sudo echo 100 > /sys/class/soft_pwm/pwm-23/duty_cycle
sudo echo 500 > /sys/class/soft_pwm/pwm-23/frequency
sudo echo 24 > /sys/class/soft_pwm/export
sudo chmod 666 /sys/class/soft_pwm/pwm-24/duty_cycle
sudo chmod 666 /sys/class/soft_pwm/pwm-24/frequency
sudo echo 100 > /sys/class/soft_pwm/pwm-24/duty_cycle
sudo echo 500 > /sys/class/soft_pwm/pwm-24/frequency
if test ! -d /sys/class/gpio/gpio17; then sudo echo 17 > /sys/class/gpio/export; fi
sudo echo out > /sys/class/gpio/gpio17/direction
sudo echo 0 > /sys/class/gpio/gpio17/value
sleep 1
sudo echo 1 > /sys/class/gpio/gpio17/value
if test ! -d /sys/class/gpio/gpio18; then sudo echo 18 > /sys/class/gpio/export; fi
sudo echo out > /sys/class/gpio/gpio18/direction
sudo echo 1 > /sys/class/gpio/gpio18/value
exit 0
Das setzen von GPIO18 auf 1 sollte unerheblich sein. Die Dokumentation auf der Busware-Seite sagt klar, dass zum Betrieb des SCC Moduls GPIO18 entweder gar nicht, oder halt auf HIGH gesetzt werden muss.
Was kann es sonst also noch sein?
EDIT: Es sieht im Moment so aus, als ob das SCC Modul nach jedem Neustart nicht mehr funktioniert. Erst nachdem ich die fhem.cfg aufgerufen und gespeichert habe, wird mir für credit10ms auch wieder was angezeigt und im Log tauchen die Messwerte auf...
Ideen? Ich kann nicht nach jedem Neustart, und schon gar nicht jede Nacht, die fhem.cfg einmal öffnen und speichern.
Problem gelöst, vorerst ...
Grund für diese Probleme mit dem nicht funktionierenden SCC Modul war einfach, dass FHEM per init.d deutlich früher gestartet wird, als die rc.local ausgeführt wird. Damit sind beim Start von FHEM die GPIO-Ports nicht initialisiert und FHEM kackt ab, bis man FHEM quasi reloaded hat, indem man die fhem.cfg speichert ...
Workaround:
Statt nur das init_gpio.sh Skript in der rc.local aufzurufen, kill ich einfach vorher FHEM und starte es danach wieder.
/etc/init.d/fhem stop
/usr/local/bin/init_gpio.sh
/etc/init.d/fhem start
Scheint bisher zu funktionieren.
Mein alternativer Lösungsansatz den Start von FHEM einfach nach hinten zu verlagern, so dass FHEM nach dem Ausführen der rc.local gestartet wird, hat leider nicht funktioniert, wobei ich nicht ausschließen möchte, dass ich etwas vergessen oder falsch gemacht habe.
for i in 0 1 6; do sudo mv /etc/rc$i.d/K01fhem /etc/rc$i.d/K10fhem; done;
for i in 2 3 4 5; do sudo mv /etc/rc$i.d/S01fhem /etc/rc$i.d/S10fhem; done;