Originally posted by: <email address deleted>
Guten Abend
Ich heisse Stephan und habe gerade eben begonnen, mich mit FHEM zu
befassen.
Ich habe einen RaspberryPi mit dem COC Modul von Busware.
Installiert habe ich das Image direkt con der Busware Homepage.
Das COC läuft
COC_MSGCNT 8
COC_TIME 2012-10-12 18:25:36
Clients :FS20:FHT:FHT8V:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX
DEF
/dev/ttyAMA0@38400 1234
DeviceName
/dev/ttyAMA0@38400
FD
4
FHTID
1234
NAME
COC
NR
8
PARTIAL
RAWMSG
SAC68C5011E000000000000003F6E03803A
RSSI
-45
STATE
Initialized
TYPE
CUL
VERSION
V 1.47 CSM868
initString
X21
Readings
raw
No answer 2012-10-12 16:54:05
Nun wollte ich einen ESA1000WZ_LED empfangen, dieser wird auch
erkannt, aber es erfolgt keine Ausgabe und kein Plot. Unten ein Auszug
aus dem Log
2012-10-12_18:25:35 ESA2000_011e repeat: -
2012-10-12_18:25:35 ESA2000_011e sequence: 44
2012-10-12_18:25:35 ESA2000_011e
2012-10-12_18:25:35 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e ticks_kwh: 921
2012-10-12_18:25:36 ESA2000_011e raw: CNT: 44- CUM: 0 CUR: 0 TICKS:
921 HR
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e diff_sec: 1376
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e last_sec: 1350066335
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e rate: HR
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e
2012-10-12_18:25:36 ESA2000_011e CNT: 44- CUM: 0.000 CUR: 0.000 TICKS:
921 HR
Ausserdem wollte ich versuchen eine bestehende Intertechno PAR-1500 zu
Testzwecken schalten. im FHEM Ordner befinden sich jedoch nur 5
10_*.pm Dateien, aber keine 10_IT.pm.
Habe ein apt-get update und ein upgrade gemacht. Wie komme ich jetzt
an die 10_IT.pm?
Besten Dank.
Gruss
Stephan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi Stephan,
hast du schon updatefhem durchgeführt ? Der Befehl wird im fhem eingegeben
(in der der Textbox mit dem save Button)
nur updatefhem eingeben und Enter drücken (nicht save) und etwas
warten...Je nachdem wie "alt" die fhem Version ist muss
updatefhem ggf, mit dem Housekeeping parameter aufgerufen werden - Das gibt
dir jedoch updatefhem schon zurück.
Damit neue Devices erkannt werden muss in der fhem.cfg der Eintrag
vorhanden sein:
define autocreate autocreate
attr autocreate device_room %TYPE
attr autocreate filelog /var/log/fhem/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
Hoffe das diese Antwort hilfreich war :-)
Gruß Dennis
Am Freitag, 12. Oktober 2012 20:38:25 UTC+2 schrieb mikka:
>
> Guten Abend
>
> Ich heisse Stephan und habe gerade eben begonnen, mich mit FHEM zu
> befassen.
> Ich habe einen RaspberryPi mit dem COC Modul von Busware.
> Installiert habe ich das Image direkt con der Busware Homepage.
> Das COC läuft
>
> COC_MSGCNT 8
> COC_TIME 2012-10-12 18:25:36
> Clients :FS20:FHT:FHT8V:KS300:USF1000:BS:HMS:
> :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX
> DEF
> /dev/ttyAMA0@38400 1234
> DeviceName
>
> /dev/ttyAMA0@38400
> FD
>
> 4
> FHTID
>
> 1234
> NAME
>
> COC
> NR
>
> 8
> PARTIAL
>
> RAWMSG
>
> SAC68C5011E000000000000003F6E03803A
> RSSI
>
> -45
> STATE
>
> Initialized
> TYPE
>
> CUL
> VERSION
>
> V 1.47 CSM868
> initString
>
> X21
>
> Readings
> raw
> No answer 2012-10-12 16:54:05
>
> Nun wollte ich einen ESA1000WZ_LED empfangen, dieser wird auch
> erkannt, aber es erfolgt keine Ausgabe und kein Plot. Unten ein Auszug
> aus dem Log
>
> 2012-10-12_18:25:35 ESA2000_011e repeat: -
> 2012-10-12_18:25:35 ESA2000_011e sequence: 44
> 2012-10-12_18:25:35 ESA2000_011e
> 2012-10-12_18:25:35 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e ticks_kwh: 921
> 2012-10-12_18:25:36 ESA2000_011e raw: CNT: 44- CUM: 0 CUR: 0 TICKS:
> 921 HR
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e diff_sec: 1376
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e last_sec: 1350066335
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e rate: HR
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e CNT: 44- CUM: 0.000 CUR: 0.000 TICKS:
> 921 HR
>
> Ausserdem wollte ich versuchen eine bestehende Intertechno PAR-1500 zu
> Testzwecken schalten. im FHEM Ordner befinden sich jedoch nur 5
> 10_*.pm Dateien, aber keine 10_IT.pm.
> Habe ein apt-get update und ein upgrade gemacht. Wie komme ich jetzt
> an die 10_IT.pm?
>
> Besten Dank.
>
> Gruss
> Stephan
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi,
jepp, 10_IT.pm ist Bestandteil der Auslieferung, sollte sich also schon auf
Deinem System befinden im Ordner FHEM. Wenn Du's noch nicht auf Deiner box
hast, am besten per updatefhem holen.
Alternativ selbst aus SVN runterladen:
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/?sortby=file
Dann IT definieren gemäß
http://fhem.de/commandref.html#IT
Viel Erfolg,
Gruß, Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Besten Dank für Eure Hilhe. Ein FHEMupdate hat schon ein paar Neuerungen
gebracht. Hatte gedacht, das Image sei auf dem neusten Stand, da es von
Ende August stamm, das Modul IT gibts ja bereits seit Anfang Jahr...
Der Aktor erschient jetzt
DEF
F000F0000F FF 0F
NAME
Test
NR
21
STATE
off
TYPE
IT
XMIT
f000f0000f
XMITdimdown
00
XMITdimup
00
XMIToff
0f
XMITon
ff
Readings
state
off2012-10-12 20:18:06
Test
IODev
COC
deleteattr
room
XYZ
deleteattr
aber es rührt sich nichts. Auf meiner PAR-1500 gibts nur einen Regler,
ABCD, jeweils 1-3. Für B2 müsste ja eigentlich der Code F000F0000F FF 0F
passen.
Jedenfalls sieht jetzt auch die Oberfläche scho ganz anders aus;-)
Gruss
Stephan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Noch etwas.
Dies eine Log Ausgabe. Keine I/O device found. Dies müsste ja eigentlich
der COC sein, denn ich in der Config auch als IODev attr definiert habe.
Oder habe ich da etwas falsch verstanden?
Gruss Stephan
Opening COC device /dev/ttyAMA0
2012.10.12 20:51:40 3: Setting COC baudrate to 38400
2012.10.12 20:51:40 3: COC device opened
2012.10.12 20:51:40 3: COC: Possible commands: mCFAZOGMRTVWXefltux
2012.10.12 20:51:40 3: No I/O device found for Test
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Rfmode vom COC richtig eingestellt ? (attr COC rfmode SlowRF)
http://www.fhemwiki.de/wiki/Rfmode
Poste mal wie deine fhem.cfg
Gruß Christoph
Am Freitag, 12. Oktober 2012 22:55:21 UTC+2 schrieb mikka:
>
> Noch etwas.
> Dies eine Log Ausgabe. Keine I/O device found. Dies müsste ja eigentlich
> der COC sein, denn ich in der Config auch als IODev attr definiert habe.
> Oder habe ich da etwas falsch verstanden?
>
> Gruss Stephan
>
>
> Opening COC device /dev/ttyAMA0
> 2012.10.12 20:51:40 3: Setting COC baudrate to 38400
> 2012.10.12 20:51:40 3: COC device opened
> 2012.10.12 20:51:40 3: COC: Possible commands: mCFAZOGMRTVWXefltux
> 2012.10.12 20:51:40 3: No I/O device found for Test
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Besten Dank.
Am rfmode habe ich nichts gedreht. Laut commandrf ist SlowRF default. Werde
es mal probieren.
Hier noch meine fhem.cfg
attr global autoload_undefined_devices 1
attr global logfile /var/log/fhem/fhem-%Y-%m.log
attr global modpath /usr/share/fhem
attr global port 7072 global
attr global statefile /var/log/fhem/fhem.save
attr global userattr webCmd
attr global verbose 3
define WEB FHEMWEB 8083 global
define WEBphone FHEMWEB 8084 global
attr WEBphone smallscreen 1
define WEBtablet FHEMWEB 8085 global
attr WEBtablet touchpad 1
define Logfile FileLog /var/log/fhem/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog /var/log/fhem/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
define initialUsbCheck notify global:INITIALIZED usb create
define COC CUL /dev/ttyAMA0@38400 1234
define ESA2000_011e ESA2000 011e
attr ESA2000_011e model ESA2000_LED
attr ESA2000_011e room Waschküche
define FileLog_ESA2000_011e FileLog /var/log/fhem/ESA2000_011e-%Y.log
ESA2000_011e
attr FileLog_ESA2000_011e logtype text
attr FileLog_ESA2000_011e room ESA2000
define Test IT F000F0000F FF 0F
attr Test IODev COC
attr Test room XYZ
define Garagentor FS20 43214321 1234
attr Garagentor model fs20tfk
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Hallo,
> habe auch ein Problem mit COC...... sagt mir immer:
>
>
2012.10.13 10:25:09 3: Opening COC device /dev/ttyAMA0
2012.10.13 10:25:09 3: Setting COC baudrate to 38400
2012.10.13 10:25:09 3: COC device opened
2012.10.13 10:25:09 1: Not an CUL device, got for V: 1.47 CSM868
verstehe ich nicht ????????
Grüße
woody
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi,
nur so als Idee: mal Baudrate runtersetzen?
=8-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Baudrate 38400 ist für ein COC richtig.
Verwendest du die aktuelle Version von OWX?
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hier meine beiden Zeilen aus meiner fhem.cfg
define COC_RPi CUL /dev/ttyAMA0@38400 0001
attr COC_RPi model CUL
VG Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 2012.10.13 10:25:09 1: Not an CUL device, got for V: 1.47 CSM868
V verschluckt.
Bei einem richtigen Antwort waere es "got for V: V 1.47 CSM868"
Nochmal probieren?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
funktioniert jetzt......selbst schuld wenn man den COC nicht flasht.......
Aber noch was anderes, nach gewisser Zeit freezt der RPI bzw FHEM ist
nicht mehr erreichbar.Ein Ping bringt auh nichts.
Kann es sein das der RPI in Stromsparmodus geht und das Netztwerk
abschaltet? Nach einem reboot funktioniert wieder alles.
Grüße
Woody
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Kann ich bestätigen.
Ich kann noch nicht ausmachen, ob der RPi oder das COC das Problem macht,
aber nach einiger Zeit (mal ein paar Stunden, mal zwei Tage) läuft nicht
mehr viel.
Meisst wird das Log wird mit wilden Meldungen vom COC zugemüllt, oder (eher
selten) der RPi selber ist nicht mehr dabei.
Als Alternative zur 7390 imho noch nicht einsetzbar.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Welche Distribution habt Ihr installiert? Hört sich nach Kernel-Problemen bzw. Treiber-Problemen an.
Setze zwar noch kein FHEM mit RPI ein, hatte aber auch Stabilitätsprobleme mit Debian squeeze. Mit Wheezy laufen bei mir zwei RPI stabil ohne Hänger.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...um die COC Erweiterung nutzen zu können, nutze ich das Kernel Image von
busware. Daher hab ich da keine grosse Möglichkeit etwas zu ändern.
Vielleicht probier ich mal den Weg die Patches selber in den Kernel zu
kompilieren, damit ich wieder in den Genuss der Updates komme.
Aber derzeit scheint es mir das es da noch so viele Baustellen gibt, das
man wohl noch was warten muss. Auf jeden Fall hab ich mal alles auf
Auslieferungszustand gesetzt (also den RPi nicht übertaktet), um
zusätzliche Fehlerquellen auszuschliessen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich habe das busware Image laufen und kann derzeit keine Probleme
feststellen.
Diese Woche laufen weitere Tests und aller voraussicht nach werde ich die
"Lebenserhaltenden" Systeme des Hauses ab nächste Woche von RPi-COC
durchführen lassen und den grossen Server abschalten/anderweitig nutzen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich hab da sehr stark Onewire im Verdacht - vielleicht mal owfs nutzen und HAS_ONEWIRE in culfw ausschalten. BEIDES ZUSAMMEN GEHT NICHT!
Ich erweitere gerade das busware-Image um einen Watchdog. Für alle die den per Hand selbst nachinstallieren möchten:
http://pi.gadgetoid.co.uk/post/001-who-watches-the-watcher
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich auch....
Am Sonntag, 14. Oktober 2012 14:53:40 UTC+2 schrieb DT:
>
>
> Ich hab da sehr stark Onewire im Verdacht -
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich habe jetzt nochmal das Image frisch aufgespielt, alles was senden
könnte deaktiviert und werde danach zuerst das fhemupdate machen.
Habe immer untenstehende Einträge.
2012.10.13 07:39:52 2: COC: unknown message DA364
2012.10.13 07:39:52 2: COC: unknown message 0464
2012.10.13 07:39:52 2: COC: unknown message 9464
2012.10.13 07:39:52 2: COC: unknown message 9464
2012.10.13 07:39:52 2: COC: unknown message 979E
2012.10.13 07:39:52 2: COC: unknown message 82CF
Könnte aber auch mit dem ESA1000WZ-Led zusammenhängen. der wird immer noch nicht richtig erkannt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo zusammen,
bin ganz frisch hier.
Habe seit Monaten FHEM auf einer Synology mit dem FHZ1300 PC ohne Problem
laufen.
Nun habe ich da ganze mit RaspberryPi und dem COC versucht.
Prinzipiell gehts, allerdings erhalte ich von den FHT80 KEINE akt.
Temperaturen sondern NUR die Werte der Ventilstellung.
In den Logs gibt es nur die 'actuator'-Zeilen. Beispiel siehe unten. Das
ist bei allen meinen FHTs (4 weitere) genau so.
Die alte Anordnung mit Synology und FHZ1300 läuft parallel mit und macht
Alles richtig.
Ich denke, da ist in der COC-Software noch ein Problem. Meine COC-Version
ist 'V1.1 FULL 2012-10-05'
Danke für Info
Gruß
Reinhard
Beispiel:
2012-10-14_08:15:14 Bad actuator: 38%
2012-10-14_08:17:13 Bad actuator: 38%
2012-10-14_08:19:11 Bad actuator: 38%
2012-10-14_08:21:10 Bad actuator: 38%
2012-10-14_08:23:08 Bad actuator: 38%
2012-10-14_08:25:07 Bad actuator: 0%
2012-10-14_08:27:05 Bad actuator: 0%
Am Freitag, 12. Oktober 2012 20:38:25 UTC+2 schrieb mikka:
>
> Guten Abend
>
> Ich heisse Stephan und habe gerade eben begonnen, mich mit FHEM zu
> befassen.
> Ich habe einen RaspberryPi mit dem COC Modul von Busware.
> Installiert habe ich das Image direkt con der Busware Homepage.
> Das COC läuft
>
> COC_MSGCNT 8
> COC_TIME 2012-10-12 18:25:36
> Clients :FS20:FHT:FHT8V:KS300:USF1000:BS:HMS:
> :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX
> DEF
> /dev/ttyAMA0@38400 1234
> DeviceName
>
> /dev/ttyAMA0@38400
> FD
>
> 4
> FHTID
>
> 1234
> NAME
>
> COC
> NR
>
> 8
> PARTIAL
>
> RAWMSG
>
> SAC68C5011E000000000000003F6E03803A
> RSSI
>
> -45
> STATE
>
> Initialized
> TYPE
>
> CUL
> VERSION
>
> V 1.47 CSM868
> initString
>
> X21
>
> Readings
> raw
> No answer 2012-10-12 16:54:05
>
> Nun wollte ich einen ESA1000WZ_LED empfangen, dieser wird auch
> erkannt, aber es erfolgt keine Ausgabe und kein Plot. Unten ein Auszug
> aus dem Log
>
> 2012-10-12_18:25:35 ESA2000_011e repeat: -
> 2012-10-12_18:25:35 ESA2000_011e sequence: 44
> 2012-10-12_18:25:35 ESA2000_011e
> 2012-10-12_18:25:35 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e ticks_kwh: 921
> 2012-10-12_18:25:36 ESA2000_011e raw: CNT: 44- CUM: 0 CUR: 0 TICKS:
> 921 HR
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e diff_sec: 1376
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e last_sec: 1350066335
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e rate: HR
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e
> 2012-10-12_18:25:36 ESA2000_011e CNT: 44- CUM: 0.000 CUR: 0.000 TICKS:
> 921 HR
>
> Ausserdem wollte ich versuchen eine bestehende Intertechno PAR-1500 zu
> Testzwecken schalten. im FHEM Ordner befinden sich jedoch nur 5
> 10_*.pm Dateien, aber keine 10_IT.pm.
> Habe ein apt-get update und ein upgrade gemacht. Wie komme ich jetzt
> an die 10_IT.pm?
>
> Besten Dank.
>
> Gruss
> Stephan
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Habe jetzt mal neu aufgesetzt, updatfhem gemacht und über putty am pi die
Zone und Uhrzeit eingestellt.
Dort kriege ich jetzt aber eine Zeile von wegen Possible commands. ex hängt
das auch damit zusammen.
2012.10.14 15:47:40 0: Server shutdown
2012.10.14 15:48:09 1: Including /etc/fhem.cfg
2012.10.14 15:48:11 3: WEB: port 8083 opened
2012.10.14 15:48:11 3: WEBphone: port 8084 opened
2012.10.14 15:48:11 3: WEBtablet: port 8085 opened
2012.10.14 15:48:12 3: Opening COC device /dev/ttyAMA0
2012.10.14 15:48:12 3: Setting COC baudrate to 38400
2012.10.14 15:48:12 3: COC device opened2012.10.14 15:48:12 3: COC: Possible commands: mCFAZOGMRTVWXefltux
2012.10.14 15:48:12 1: Including /var/log/fhem/fhem.save
2012.10.14 15:48:12 3: Converting 'attr global port 7072 global' to 'define telnetPort telnet 7072 global'
2012.10.14 15:48:12 3: telnetPort: port 7072 opened
2012.10.14 15:48:12 1: usb create starting
2012.10.14 15:48:14 1: usb create end
2012.10.14 15:48:14 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.
2012.10.14 15:48:14 0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1946 2012-10-11 18:11:14
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
habe seit 14 Tagen RPi + COC + FHEM laufen. Die Konstellation auch mit drei
FHTs läuft einwandfrei. Im Log sind alle Werte vorhanden. Meine COC-Version
ist V 1.47 CSM868.
Grüße
Jörg
Am Sonntag, 14. Oktober 2012 15:47:21 UTC+2 schrieb rxf:
> Hallo zusammen,
>
> bin ganz frisch hier.
> Habe seit Monaten FHEM auf einer Synology mit dem FHZ1300 PC ohne Problem
> laufen.
>
> Nun habe ich da ganze mit RaspberryPi und dem COC versucht.
> Prinzipiell gehts, allerdings erhalte ich von den FHT80 KEINE akt.
> Temperaturen sondern NUR die Werte der Ventilstellung.
> In den Logs gibt es nur die 'actuator'-Zeilen. Beispiel siehe unten. Das
> ist bei allen meinen FHTs (4 weitere) genau so.
> Die alte Anordnung mit Synology und FHZ1300 läuft parallel mit und macht
> Alles richtig.
>
> Ich denke, da ist in der COC-Software noch ein Problem. Meine COC-Version
> ist 'V1.1 FULL 2012-10-05'
>
> Danke für Info
>
> Gruß
> Reinhard
>
> Beispiel:
>
> 2012-10-14_08:15:14 Bad actuator: 38%
> 2012-10-14_08:17:13 Bad actuator: 38%
> 2012-10-14_08:19:11 Bad actuator: 38%
> 2012-10-14_08:21:10 Bad actuator: 38%
> 2012-10-14_08:23:08 Bad actuator: 38%
> 2012-10-14_08:25:07 Bad actuator: 0%
> 2012-10-14_08:27:05 Bad actuator: 0%
>
>
>
> Am Freitag, 12. Oktober 2012 20:38:25 UTC+2 schrieb mikka:
>>
>> Guten Abend
>>
>> Ich heisse Stephan und habe gerade eben begonnen, mich mit FHEM zu
>> befassen.
>> Ich habe einen RaspberryPi mit dem COC Modul von Busware.
>> Installiert habe ich das Image direkt con der Busware Homepage.
>> Das COC läuft
>>
>> COC_MSGCNT 8
>> COC_TIME 2012-10-12 18:25:36
>> Clients :FS20:FHT:FHT8V:KS300:USF1000:BS:HMS:
>> :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX
>> DEF
>> /dev/ttyAMA0@38400 1234
>> DeviceName
>>
>> /dev/ttyAMA0@38400
>> FD
>>
>> 4
>> FHTID
>>
>> 1234
>> NAME
>>
>> COC
>> NR
>>
>> 8
>> PARTIAL
>>
>> RAWMSG
>>
>> SAC68C5011E000000000000003F6E03803A
>> RSSI
>>
>> -45
>> STATE
>>
>> Initialized
>> TYPE
>>
>> CUL
>> VERSION
>>
>> V 1.47 CSM868
>> initString
>>
>> X21
>>
>> Readings
>> raw
>> No answer 2012-10-12 16:54:05
>>
>> Nun wollte ich einen ESA1000WZ_LED empfangen, dieser wird auch
>> erkannt, aber es erfolgt keine Ausgabe und kein Plot. Unten ein Auszug
>> aus dem Log
>>
>> 2012-10-12_18:25:35 ESA2000_011e repeat: -
>> 2012-10-12_18:25:35 ESA2000_011e sequence: 44
>> 2012-10-12_18:25:35 ESA2000_011e
>> 2012-10-12_18:25:35 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e ticks_kwh: 921
>> 2012-10-12_18:25:36 ESA2000_011e raw: CNT: 44- CUM: 0 CUR: 0 TICKS:
>> 921 HR
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e diff_sec: 1376
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e last_sec: 1350066335
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e rate: HR
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e
>> 2012-10-12_18:25:36 ESA2000_011e CNT: 44- CUM: 0.000 CUR: 0.000 TICKS:
>> 921 HR
>>
>> Ausserdem wollte ich versuchen eine bestehende Intertechno PAR-1500 zu
>> Testzwecken schalten. im FHEM Ordner befinden sich jedoch nur 5
>> 10_*.pm Dateien, aber keine 10_IT.pm.
>> Habe ein apt-get update und ein upgrade gemacht. Wie komme ich jetzt
>> an die 10_IT.pm?
>>
>> Besten Dank.
>>
>> Gruss
>> Stephan
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Das hier ist ein Auszug aus dem Log von heute.
Hardware: RPi mit COC (rfmode HomeMatic) und CUL
OneWire mit einem einzelnen DS1820 an einem 30cm langem Kabel
Das Verhalten ist identisch mit dem der FB7390 mit CUL & 2x CUNO, und
einigen 1-Wire Devices.
2012.10.14 07:20:45 1: Including /var/log/fhem/fhem.save
2012.10.14 07:20:45 1: usb create starting
2012.10.14 07:20:47 1: usb create end
2012.10.14 07:20:47 0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id:
fhem.pl 1946 2012-10-11 18:11:14Z borisneubert $, pid 1896)
2012.10.14 07:20:56 1: OWX: 1-Wire devices found on bus 1wire_RPi:
(RPi_T_Test)
2012.10.14 09:45:52 1: OWX: Received unexpected number of 17 bytes from CUNO
2012.10.14 10:40:52 1: OWX: Received unexpected number of 24 bytes from CUNO
2012.10.14 10:40:52 1: OWX: Received unexpected number of 15 bytes from CUNO
2012.10.14 12:05:52 1: OWX: Received unexpected number of 39 bytes from CUNO
2012.10.14 12:55:52 1: OWX: Received unexpected number of 32 bytes from CUNO
2012.10.14 12:55:52 1: OWX: Received unexpected number of 11 bytes from CUNO
2012.10.14 13:10:52 1: OWX: Received unexpected number of 24 bytes from CUNO
2012.10.14 13:10:52 1: OWX: Received unexpected number of 13 bytes from CUNO
2012.10.14 13:10:53 1: OWX: Received unexpected number of 12 bytes from CUNO
2012.10.14 13:10:53 1: OWX: Received unexpected number of 31 bytes from CUNO
2012.10.14 13:25:52 1: OWX: Received unexpected number of 24 bytes from CUNO
2012.10.14 13:40:52 1: OWX: Received unexpected number of 12 bytes from CUNO
2012.10.14 13:40:52 1: OWX: Received unexpected number of 25 bytes from CUNO
2012.10.14 13:50:52 1: OWX: Received unexpected number of 24 bytes from CUNO
2012.10.14 13:50:52 1: OWX: Received unexpected number of 13 bytes from CUNO
Was neu ist, ist z.B. das von heute Nacht / heute Morgen.
2012.10.14 07:10:17 2: COC_RPi: unknown message 09
2012.10.14 07:10:18 2: COC_RPi: unknown message 986701938BE00000000C63A22
2012.10.14 07:10:20 2: COC_RPi: unknown message
0000D867019DF1F00000000C13B06
2012.10.14 07:10:30 2: COC_RPi: unknown message 00003A25819E4F419B2AF001007
2012.10.14 07:10:30 2: COC_RPi: unknown message
DCC13820219B2AF19E4F401010C003901
2012.10.14 07:10:37 2: COC_RPi: unknown message 010CAA25819E2C819DDFA00111E
2012.10.14 07:10:37 2: COC_RPi: unknown message
DB73A820219DDFA19E2C801010E0033FD
2012.10.14 07:10:38 2: COC_RPi: unknown message 014E9A2581938BE193A80003D22
2012.10.14 07:10:38 2: COC_RPi: unknown message
DB9898202193A801938BE010130004418
2012.10.14 07:10:40 2: COC_RPi: unknown message 0100DA25819DF1F19DB98000008
2012.10.14 07:10:40 2: COC_RPi: unknown message
3A80D820219DB9819DF1F010100003117
2012.10.14 07:10:58 2: COC_RPi: unknown message
01300867019E56B00000000BD3FFE
2012.10.14 07:11:13 2: COC_RPi: unknown message
00003867019DEAF00000000C242FC
2012.10.14 07:11:18 2: COC_RPi: unknown message
00000820219DB7319E56B01014E00311E
2012.10.14 07:11:33 2: COC_RPi: unknown message 7CF73A25819DEAF19D8AC007CFB
2012.10.14 07:11:34 2: COC_RPi: unknown message
01603820219D8AC19DEAF010160003AEE
2012.10.14 07:11:36 2: COC_RPi: unknown message
BA3E086701B18F400000000BE4101
2012.10.14 07:11:44 2: COC_RPi: unknown message
B93E3867019E3D600000000B93E0A
2012.10.14 07:11:56 2: COC_RPi: unknown message
42ED0820219DB871B18F401015A002EF0
2012.10.14 07:12:15 2: COC_RPi: unknown message 2EEDAA25819E24F19DC9C0030F5
2012.10.14 07:12:15 2: COC_RPi: unknown message
0000A820219DC9C19E24F0101260041F2
2012.10.14 07:12:27 2: COC_RPi: unknown message 38064A2581B18B419DB40000003
2012.10.14 07:12:27 2: COC_RPi: unknown message
8F3C4820219DB401B18B4010100003709
2012.10.14 07:12:27 2: COC_RPi: unknown message 6
2012.10.14 07:12:28 2: COC_RPi: unknown message 0B867019E2C800000000B93A1D
2012.10.14 07:12:29 2: COC_RPi: unknown message 32
2012.10.14 07:12:35 2: COC_RPi: unknown message 1A25819E41919D913005AF7
2012.10.14 07:12:35 2: COC_RPi: unknown message
3A1E1820219D91319E419010146002F16
2012.10.14 07:12:48 2: COC_RPi: unknown message 06
2012.10.14 07:12:49 2: COC_RPi: unknown message
B820219DDFA19E2C801010E0033E7
2012.10.14 07:13:08 3: COC_RPi: Unknown code E238A86701938BE00000000C63A,
help me!
2012.10.14 07:13:15 2: COC_RPi: unknown message FD
2012.10.14 07:13:16 2: COC_RPi: unknown message 4867019DEAF00000000C242F7
2012.10.14 07:13:28 2: COC_RPi: unknown message 4418AA2581938BE193A80003D1F
2012.10.14 07:13:28 2: COC_RPi: unknown message
0008A8202193A801938BE01013000411C
2012.10.14 07:13:30 2: COC_RPi: unknown message 31174A25819E4F419DCC1001008
2012.10.14 07:13:30 2: COC_RPi: unknown message
BD3F4820219DCC119E4F401010C003503
2012.10.14 07:13:30 2: COC_RPi: unknown message FC
2012.10.14 07:13:35 3: COC_RPi: Unknown code EA25819DF1F19DB980000, help me!
2012.10.14 07:13:35 2: COC_RPi: unknown message
4E00E820219DB9819DF1F010100003117
2012.10.14 07:13:35 2: COC_RPi: unknown message FB
2012.10.14 07:13:36 2: COC_RPi: unknown message 4A25819DEAF19D8AC007CF9
2012.10.14 07:13:36 2: COC_RPi: unknown message
60004820219D8AC19DEAF010160003AF2
2012.10.14 07:13:36 2: COC_RPi: unknown message 41011A25819E56B19DB730064F2
2012.10.14 07:13:36 2: COC_RPi: unknown message
00001820219DB7319E56B01014E00311C
2012.10.14 07:13:49 2: COC_RPi: unknown message
00B34867019E3D600000000B93E08
2012.10.14 07:14:09 2: COC_RPi: unknown message 00744A25819E3D61888B200000B
2012.10.14 07:14:09 2: COC_RPi: unknown message
0101482021888B219E3D6010100003E04
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 14.10.2012 16:04, schrieb mikka:
> Dort kriege ich jetzt aber eine Zeile von wegen Possible commands. ex
> hängt das auch damit zusammen.
> 2012.10.14 15:48:12 3: COC device opened
> 2012.10.14 15:48:12 3: COC: Possible commands: mCFAZOGMRTVWXefltux
> 2012.10.14 15:48:12 1: Including /var/log/fhem/fhem.save
Nein, das ist eine reine Logausgabe. Zeigt nur das, was es sagt :-)
Gruß
Jens
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ach der sprich mit mir ;-)
Gruss Stephan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich kann nur bestätigen, dass der RPi und das COC zusammen mit FHTs, FS20
und diversen 1-Wire Devices zusammen wunderbar laufen. Inwischen 2 Wochen
ohne Probleme, und langsam migriere ich das Gesamtsystem von der Fritzbox
auf den RPi.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@mikka,JoWiemann:
Ich kann nur bestätigen, dass der RPi und das COC zusammen mit FHTs, FS20
und diversen 1-Wire Devices zusammen wunderbar laufen.
Inwischen 2 Wochen ohne Probleme, und langsam migriere ich das Gesamtsystem
von der Fritzbox auf den RPi.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo pha
Besten Dank für die Info, dann werde ich mich noch weiter reinhängen. Ein
FS20 TFK läuft soweit, mit dem Rest habe ich noch so meine Mühe. Das
ESA1000/2000WZ erhält zwar einen Autocreate Eintrag und mit anpassen der
64_esa2000.pm erhalte ich auch Daten, aber keine verlässlichen Werte. Ev.
habe ich aber auch beim löten etwas falsch gemacht. Da ich sowieso noch
einen 2ten brauche, habe ich mir jetzt das Fertigset bestellt. Mal schauen
ob da was rauskommt.
Einen HM Schalter habe ich noch nicht zum laufen gekriegt. Habe keinen
Taster vor Ort und wollte ihn direkt übwer die Seriennummer anlernen,
erhalte aber eine unknown Ausgabe, wenn ich es mit hmPairSerial
versuche.
Gruss
Stephan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
ich hatte es erst mit dem 5.x versucht, aber da gabs immer die freezes.Also
verwende ich jetzt die 5.2 mit dem Busware Immage das läuft seit 2 Tagen.
Allerdings hab ich die enocean.pm gegen die neue ausgetauscht, da mir
enocean falsche Aussentemperaturwerte lieferte. Jetzt ist es OK. Auch die
Temperaturabfrage an einem ECMD Device (Pollin AVR-Net-IO) funktioniert,
sogar im Minutenrhytmus.. Am COC habe ich 1-Wire noch nicht ausprobiert.
Bei der 5.x gabs ein freez wenn man dasavr- net-io reopend hat. In wieweit
das reproduzierbar ist, weiß ich nicht. Mein 2. rpi ist seit 3 Monaten bei
RS bestellt, kommt aber irgendwie nicht.
Ich hatte vorher den rpi ohne coc mit der wheezy laufen, das hat auch
funktioniert.
Grüße
woody
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Heute mal was anderes:
Hab gerade bemerkt, das fhem auf dem RPi (mein Testsystem) sich nicht mehr
meldet.
Also Monitor vom RPi an.... dunkel... also mal neu booten
-> Kernel Panic -> Partition auf der MMC Karte korrupt ...
Immerhin ne SanDisk Ultra II ... Tscha.
Naja, aber der RPi lief im Stress-Test bei 1 GHz. Werde also noch mal etwas
runter schalten und weiter probieren.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
SD Card Corruption ist ein bekannter Fehler im Turbomodus, derzeit gibt es
noch keinen Fix der immer funktioniert.
Tritt allerdings nur mit SD-Karten auf, wenn man das BS auf einem USB-Stick
hat, hat man das Problem nicht.
Am Freitag, 19. Oktober 2012 07:44:05 UTC+2 schrieb dou...@m1n1.de:
>
>
>
> Heute mal was anderes:
>
> Hab gerade bemerkt, das fhem auf dem RPi (mein Testsystem) sich nicht mehr
> meldet.
> Also Monitor vom RPi an.... dunkel... also mal neu booten
>
> -> Kernel Panic -> Partition auf der MMC Karte korrupt ...
>
> Immerhin ne SanDisk Ultra II ... Tscha.
>
> Naja, aber der RPi lief im Stress-Test bei 1 GHz. Werde also noch mal
> etwas runter schalten und weiter probieren.
>
> VG
> Ralf
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Interessant! Wusste ich bislang auch noch nicht.
Aber mein Pi hat wohl noch andere Probleme. Nachdem ich die SD Karte frisch
formatiert und alles neu installiert habe, läuft er ganz bewusst nur noch
im Standard-Mode.
Sollte ja für fhem reichen.
Leider hängt er sich nach einiger Zeit dann doch auf. Reagiert nicht mehr
auf Tastatur und fhem ist auch down. Mal läuft er tagelang durch, mal ist
er morgens weg.
Blöd.
Ich bin von der Stabilität der FritzBox schon zu verwöhnt, als das ich das
Pferd in diesem Zustand wechseln würde.
Wie sieht's denn bei euch aus? Ähnliche Beobachtungen?
VG
Ralf
Am Sonntag, 21. Oktober 2012 12:38:28 UTC+2 schrieb drdownload:
>
> SD Card Corruption ist ein bekannter Fehler im Turbomodus, derzeit gibt es
> noch keinen Fix der immer funktioniert.
>
> Tritt allerdings nur mit SD-Karten auf, wenn man das BS auf einem
> USB-Stick hat, hat man das Problem nicht.
>
> Am Freitag, 19. Oktober 2012 07:44:05 UTC+2 schrieb dou...@m1n1.de:
>>
>>
>>
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
bei mir läuft der RasPi mit COC und RFXtrx433 mit dem Busware image stabil.
Gesteuert werden Intertechno Steckdosen, FS20 Schalter und Dimmer, KD101
Rauchmelder (gibts für'n 10er bei Pollin!!!!), TH300 Sensoren sowie
MEBUS/TFA Sensoren werden ausgelesen,
Ich habe overclock am RasPi auf High (950 MHz). OS image auf einer 8 GB
Standard- SD Karte.
Falls sich mal was aufhängt, restartet der watchdog den Raspberry
http://pi.gadgetoid.co.uk/post/001-who-watches-the-watcher
In 3 Wochen hatte ich laut log- file nur Hänger mit restart, läuft also
relativ stabil
Gruß
Lutz
Am Dienstag, 23. Oktober 2012 11:46:57 UTC+2 schrieb dou...@m1n1.de:
>
>
> Interessant! Wusste ich bislang auch noch nicht.
>
> Aber mein Pi hat wohl noch andere Probleme. Nachdem ich die SD Karte
> frisch formatiert und alles neu installiert habe, läuft er ganz bewusst nur
> noch im Standard-Mode.
> Sollte ja für fhem reichen.
> Leider hängt er sich nach einiger Zeit dann doch auf. Reagiert nicht mehr
> auf Tastatur und fhem ist auch down. Mal läuft er tagelang durch, mal ist
> er morgens weg.
> Blöd.
> Ich bin von der Stabilität der FritzBox schon zu verwöhnt, als das ich das
> Pferd in diesem Zustand wechseln würde.
>
> Wie sieht's denn bei euch aus? Ähnliche Beobachtungen?
>
> VG
> Ralf
>
>
> Am Sonntag, 21. Oktober 2012 12:38:28 UTC+2 schrieb drdownload:
>>
>> SD Card Corruption ist ein bekannter Fehler im Turbomodus, derzeit gibt
>> es noch keinen Fix der immer funktioniert.
>>
>> Tritt allerdings nur mit SD-Karten auf, wenn man das BS auf einem
>> USB-Stick hat, hat man das Problem nicht.
>>
>> Am Freitag, 19. Oktober 2012 07:44:05 UTC+2 schrieb dou...@m1n1.de:
>>>
>>>
>>>
>>>
>>>
>>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich hatte in 3 Wochen nur *1 *Hänger mit restart!!!!
Am Dienstag, 23. Oktober 2012 12:03:53 UTC+2 schrieb Lutz:
>
> Hallo,
> bei mir läuft der RasPi mit COC und RFXtrx433 mit dem Busware image stabil.
> Gesteuert werden Intertechno Steckdosen, FS20 Schalter und Dimmer, KD101
> Rauchmelder (gibts für'n 10er bei Pollin!!!!), TH300 Sensoren sowie
> MEBUS/TFA Sensoren werden ausgelesen,
> Ich habe overclock am RasPi auf High (950 MHz). OS image auf einer 8 GB
> Standard- SD Karte.
> Falls sich mal was aufhängt, restartet der watchdog den Raspberry
> http://pi.gadgetoid.co.uk/post/001-who-watches-the-watcher
> In 3 Wochen hatte ich laut log- file nur Hänger mit restart, läuft also
> relativ stabil
>
>
> Gruß
> Lutz
>
>
>
> Am Dienstag, 23. Oktober 2012 11:46:57 UTC+2 schrieb dou...@m1n1.de:
>>
>>
>> Interessant! Wusste ich bislang auch noch nicht.
>>
>> Aber mein Pi hat wohl noch andere Probleme. Nachdem ich die SD Karte
>> frisch formatiert und alles neu installiert habe, läuft er ganz bewusst nur
>> noch im Standard-Mode.
>> Sollte ja für fhem reichen.
>> Leider hängt er sich nach einiger Zeit dann doch auf. Reagiert nicht mehr
>> auf Tastatur und fhem ist auch down. Mal läuft er tagelang durch, mal ist
>> er morgens weg.
>> Blöd.
>> Ich bin von der Stabilität der FritzBox schon zu verwöhnt, als das ich
>> das Pferd in diesem Zustand wechseln würde.
>>
>> Wie sieht's denn bei euch aus? Ähnliche Beobachtungen?
>>
>> VG
>> Ralf
>>
>>
>> Am Sonntag, 21. Oktober 2012 12:38:28 UTC+2 schrieb drdownload:
>>>
>>> SD Card Corruption ist ein bekannter Fehler im Turbomodus, derzeit gibt
>>> es noch keinen Fix der immer funktioniert.
>>>
>>> Tritt allerdings nur mit SD-Karten auf, wenn man das BS auf einem
>>> USB-Stick hat, hat man das Problem nicht.
>>>
>>> Am Freitag, 19. Oktober 2012 07:44:05 UTC+2 schrieb dou...@m1n1.de:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...Mist.. mein RPi war heute morgen schon wieder weg. Werde jetzt mal ein
anderes Netzteil probieren. Hatte bislang mein Handy Ladegerät in
Verwendung, welches ein 1,2A Rating hat.
Hab mir letztlich bei Pollin ein paar Netzteile 5V 2,2A für nen
Euro-Fünfzig mitbestellt. Mal sehen ob das was bringt.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Liste,
möchte nach mehreren Wochen Test hier auch mal meine Nöte zum besten geben:
Der COC von Busware im Funkmodus mit FHT, FS20 etc. läuft auf 2 getesteten Raspberry Pi prima. Es funktioniert auch 1-Wire mit den OWX Modulen von Prof. Henning, aber
leider nur mit max. 2 DS18B20 oder einem DS2406 und einem DS18B20. Sobald ich mehr als zwei 1-Wire Sensoren am Bus betreibe (Testweise
auf dem Schreibtisch, ohne lange Kabel dazwischen), gehen die Device auf "abwesend". Hatte erst das vorhandene Netzteil (5V, 2A von einem USB Switch) in Verdacht und habe inzwischen ein neues Voltcraft SPS5-12W 5V Steckernetzteil gekauft. Leider lag es daran nicht - bzw. brachte keine Besserung/Veränderung.
Da ich seit ca. April 2012 einen umfangreichen 1-Wire Bus mit mehreren Switches, LCD Display, Counter und über 20 Thermosensoren an einem
Eigenbau Interface mit DS2480 über OWX äußerst stabil an der FB 7390 betreibe - bin ich letztlich ziemlich ratlos, warum das mit dem COC bei mir nicht geht - eine Idee, woran das liegen kann?
RasPi mit Raspbian & FHEM & COC patches von der busware.de Seite
Fhem mit allen Updates und der neuen Verzeichnisstruktur
OWX etc. aus dem contrib
lg det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
könnte ich den coc eigentlich auch in 433 betreiben mit passender
antenne? (cul 868 hätte ich schon)
2012/10/21 drdownload :
> SD Card Corruption ist ein bekannter Fehler im Turbomodus, derzeit gibt es
> noch keinen Fix der immer funktioniert.
>
> Tritt allerdings nur mit SD-Karten auf, wenn man das BS auf einem USB-Stick
> hat, hat man das Problem nicht.
>
> Am Freitag, 19. Oktober 2012 07:44:05 UTC+2 schrieb dou...@m1n1.de:
>>
>>
>>
>> Heute mal was anderes:
>>
>> Hab gerade bemerkt, das fhem auf dem RPi (mein Testsystem) sich nicht mehr
>> meldet.
>> Also Monitor vom RPi an.... dunkel... also mal neu booten
>>
>> -> Kernel Panic -> Partition auf der MMC Karte korrupt ...
>>
>> Immerhin ne SanDisk Ultra II ... Tscha.
>>
>> Naja, aber der RPi lief im Stress-Test bei 1 GHz. Werde also noch mal
>> etwas runter schalten und weiter probieren.
>>
>> VG
>> Ralf
>>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@det.
..also wenn ich das richtig in Erinnerung habe, hat der/das COC ab Stelle
von 3,3 wieder 5V Bus-Spannung und den "Strong-PullUp" Support für 1-Wire
Devices, die schon mal Strom brauchen aber nur parasitär betrieben werden
können.
Allerdings ist mir noch nicht klar, wie der gesteuert wird.
Hier befürchte ich aber mehr als nur eine Baustelle.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Kurzes Update an dieser Stelle:
Ich hab vor 4 Tagen das Netzteil getauscht und jetzt dieses 2,2A Pollin
Netzteil in Betrieb. Seit dem (bislang) keinerlei Hänger mehr!!
Es wird zwar an allen Ecken davon berichtet, das der RPi sensibel auf die
Spannungsversorgung reagiert, aber das 1,2A Netzteil war wohl noch zu
optimistisch.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nächstes Update:
Das stärkere Netzteil hat auf alle Fälle dafür gesorgt, das der RPi jetzt
stabil zu laufen scheint, nur gestern Abend war es dann leider doch soweit:
das COC ist ausgestiegen, und wie immer passiert das bei mir, wenn OWX mit
im Spiel ist.
Ausschnitt:
....
2012.10.30 21:11:29 2: FS20 Nachtlicht_Kueche off
2012.10.30 21:35:34 2: FS20 Nachtlicht_Treppenhaus off
2012.10.30 21:48:51 1: OWX: Received unexpected number of 24 bytes from
CUNO/COC
2012.10.30 21:48:51 1: OWX: Received unexpected number of 21 bytes from
CUNO/COC
2012.10.30 21:48:52 3: OWTHERM: Could not get values from device
RPi_OW_Test, reason invalid data
2012.10.30 21:48:53 2: COC_1: unknown message CF686701B18B400000000C7360E
2012.10.30 21:48:55 2: COC_1: unknown message 00B47A25819DEAF19D8AC000002
2012.10.30 21:48:56 2: COC_1: unknown message
01E47820219D8AC19DEAF010100003A08
2012.10.30 21:49:03 2: COC_1: unknown message 09B12A25819E4F419DCC1000009
2012.10.30 21:49:03 2: COC_1: unknown message
01E12820219DCC119E4F4010100003414
2012.10.30 21:49:13 2: COC_1: unknown message 00BF6A2581B18B419DB4000000D
2012.10.30 21:49:14 2: COC_1: unknown message
01EF6820219DB401B18B4010100003709
2012.10.30 21:49:28 2: COC_1: unknown message C3CC4867019E2C800000000BE3621
2012.10.30 21:49:43 2: COC_1: unknown message 00CB7867019DF1F00000000C33922
2012.10.30 21:49:48 2: COC_1: unknown message 00BC4A25819E2C819DDFA030D21
2012.10.30 21:49:48 2: COC_1: unknown message
00EC4820219DDFA19E2C801010010320E
2012.10.30 21:49:52 2: COC_1: unknown message CCC14867019E56B00000000C13B17
2012.10.30 21:49:55 2: COC_1: unknown message 11C3F86701B18F400000000C23DF4
2012.10.30 21:50:03 2: COC_1: unknown message 00BB7A25819DF1F19DB98000022
2012.10.30 21:50:03 2: COC_1: unknown message
80EB7820219DB9819DF1F010100003303
2012.10.30 21:50:12 2: COC_1: unknown message 0EB14A25819E56B19DB73001117
2012.10.30 21:50:12 2: COC_1: unknown message
00E14820219DB7319E56B01010E00301F
2012.10.30 21:50:15 2: COC_1: unknown message B0B3FA2581B18F419DB870009F3
2012.10.30 21:50:15 2: COC_1: unknown message
00E3F820219DB871B18F4010106002D0B
2012.10.30 21:50:22 2: COC_1: unknown message 3AC7886701938BE00000000CC3630
2012.10.30 21:50:34 2: COC_1: unknown message 00CBD867019E24F00000000B03BEE
2012.10.30 21:50:42 2: COC_1: unknown message 13B78A2581938BE193A80001930
2012.10.30 21:50:42 2: COC_1: unknown message
19E788202193A801938BE010114003633
2012.10.30 21:50:44 2: COC_1: unknown message 9CC48867019DEAF00000000CA3B01
und so weiter....
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...heute ist der/das COC wieder ausgestiegen. 10min nach einem fhem update
und einem shutdown restart.
Wie immer in Verbindung mit dem 1-Wire Bus.
Eigentlich schade aber so ist der Umstieg von der FritzBox nicht mal
ansatzweise denkbar.
Und da hilft noch nicht mal der Watchdog ...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Bei mir läuft der RasPi mit COC im parallel Betrieb zur FB sehr stabil. Nach meinen div. Nachfragen hier und https://groups.google.com/forum/m/?hl=de&fromgroups#!search/det.$20Fhemusers/fhem-users/KNn2YdjtrX8 habe ich resigniert und nutze den COC mit FS20 und nur noch testweise mit einem einzelnen DS2418 unter 1-wire. Mehr macht er nicht, schade die 1-wire Option hätte man sich offenbar bei dem Ding sparen können. Die Teile für den nächsten Eigenbauadapter mit DS2480 sind bestellt, zum Glück hat der RasPi ja 2 ungenutzte USB Buchsen. Da bin ich guter Hoffnung, das 1-wire damit dann ebenso gut mit OWX funktioniert wie an der FB. Dort hatte ich die ganzen Probleme mit Spannungsversorgung der Sensoren und Pullupwiderständen wie man sie hier im Forum von CUNO/ COC Nutzern immer wieder liest noch nie - nachdem ich dem Adapter 5V über einen aktiven USB-Hub spendiert habe.
lg det.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...ist für mich schwierig zu beurteilen, ob das jetzt OWX verursacht, oder
der/das COC
Ich denke möglicherweise trägt beides seinen Teil dazu bei, wenn ich mir
die Fehlermeldungen so ansehe, die von OWX generiert werden. (Z.B. '
ignored at /usr/share/fhem/FHEM/00_OWX.pm line 1958)
Heute morgen war wieder um 04:24 Schluss, und aktuell hängt nur ein
einzelner DS18S20 am 1-Wire Bus. Nicht auszudenken, wenn da die
Heizungssteuerung drauf laufen würde.
Ich denke aber das jeder mit COC und 1-Wire dieses Problem hat, daher habe
ich schon Hoffnung, das das irgendwann gefixed wird. Mich in culfw UND OWX
einzuarbeiten, übersteigt meine mir aktuell zur Verfügung stehende Zeit.
2012.11.06 21:29:53 2: FS20 Casa_Alarm_Signal on
2012.11.06 21:32:31 2: FS20 Casa_Alarm_Signal off
2012.11.06 21:32:32 2: FS20 Casa_Alarm_Signal off
2012.11.06 21:32:34 2: FS20 Casa_Alarm_Signal off
2012.11.06 21:35:00 2: FS20 Casa_Alarm_Signal on
2012.11.06 21:36:12 2: FS20 FS20_683901 on
2012.11.06 21:38:10 2: FS20 Nachtlicht_Treppenhaus off
2012.11.06 21:38:11 2: FS20 Nachtlicht_Kueche off
2012.11.06 21:38:11 2: FS20 Casa_Gartenlicht_Vorne off
2012.11.06 21:47:51 2: FS20 FS20_683901 off
2012.11.06 22:09:00 1: OWX: Received unexpected number of 24 bytes from
CUNO/COC
2012.11.06 22:09:00 1: OWX: Received unexpected number of 15 bytes from
CUNO/COC
2012.11.07 02:44:00 1: OWX: Received unexpected number of 24 bytes from
CUNO/COC
2012.11.07 02:44:00 1: OWX: Received unexpected number of 19 bytes from
CUNO/COC
2012.11.07 02:59:00 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.07 04:24:01 3: OWTHERM: Could not get values from device
RPi_OW_Test, reason invalid data
2012.11.07 04:24:04 2: COC_1: unknown message 0CC4867019E41900000000B73A08
2012.11.07 04:24:20 2: COC_1: unknown message 50B9FA25819E3D61888B2002AEF
2012.11.07 04:24:20 2: COC_1: unknown message
00E73820219D8AC19DEAF0101140037FC
2012.11.07 04:24:20 2: COC_1: unknown message
50E9F82021888B219E3D601012000431C
2012.11.07 04:24:24 2: COC_1: unknown message C0BC4A25819E41919D913000008
2012.11.07 04:24:24 2: COC_1: unknown message
70EC4820219D91319E419010100003228
2012.11.07 04:24:47 3: COC_1: Unknown code E0CA186701938BE00000000C036,
help me!
2012.11.07 04:24:54 3: COC_1: Unknown code E0CDE867019DF1F00000000BB38,
help me!
2012.11.07 04:24:59 2: COC_1: unknown message D0CF9867019E2C800000000B43721
2012.11.07 04:25:06 2: COC_1: unknown message 90BA1A2581938BE193A8000002D
2012.11.07 04:25:07 2: COC_1: unknown message
50EA18202193A801938BE01010000372A
2012.11.07 04:25:08 3: COC_1: Unknown code
811404xx0101a0010c4686007019e56b00000000b63b, help me!
2012.11.07 04:25:14 2: COC_1: unknown message 10BDEA25819DF1F19DB98000F1A
2012.11.07 04:25:14 2: COC_1: unknown message
10EDE820219DB9819DF1F01010C003212
2012.11.07 04:25:19 2: COC_1: unknown message 10BF9A25819E2C819DDFA003421
2012.11.07 04:25:19 2: COC_1: unknown message
70EF9820219DDFA19E2C801012800321B
2012.11.07 04:25:28 3: COC_1: Unknown code E0B46A25819E56B19DB73001C, help
me!
2012.11.07 04:25:28 2: COC_1: unknown message
D0E46820219DB7319E56B010116002F20
2012.11.07 04:26:13 2: COC_1: unknown message 10C74867019DEAF00000000B641FB
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nachtrag:
Was es auch ist: das COC hängt sich derartig weg, das kein Reset mehr
möglich ist.
Selbst nach shutdown restart kommt das COC nicht mehr hoch. Erst ein reboot
des RPi versetzt das Ganze wieder in einen normalen Zustand.
Gestern nach einigen Stunden war es sogar soweit, das die Tastatur am RPi
nicht mehr reagierte. Kein Login möglich. Da half nur noch Stecker ziehen.
2012.11.07 08:03:24 0: Server shutdown
2012.11.07 08:03:28 1: Including /etc/fhem.cfg
2012.11.07 08:03:29 3: tPort: port 7072 opened
2012.11.07 08:03:29 3: WEB: port 8083 opened
2012.11.07 08:03:29 3: WEBphone: port 8084 opened
2012.11.07 08:03:29 3: WEBtablet: port 8085 opened
2012.11.07 08:03:30 3: Opening CUL_0 device /dev/ttyACM0
2012.11.07 08:03:30 3: Setting CUL_0 baudrate to 9600
2012.11.07 08:03:30 3: CUL_0 device opened
2012.11.07 08:03:31 3: CUL_0: Possible commands: BCFiAGMRTVWXefmltux
2012.11.07 08:03:31 3: Opening COC_1 device /dev/ttyAMA0
2012.11.07 08:03:31 3: Setting COC_1 baudrate to 38400
2012.11.07 08:03:31 3: COC_1 device opened
2012.11.07 08:03:31 1: Not an CUL device, got for V: 1.47 CSM868
0C
2012.11.07 08:03:31 1: Cannot init /dev/ttyAMA0, ignoring it
2012.11.07 08:03:31 2: Switched COC_1 rfmode to HomeMatic
2012.11.07 08:03:33 1: OWX: CUNO/COC device COC_1 defined
2012.11.07 08:03:33 1: OWX: 1-Wire bus OW_RPi: interface not found, answer
was
2012.11.07 08:03:34 1: OWX: 1-Wire bus OW_RPi: interface not found, answer
was
2012.11.07 08:03:34 1: OWX: 1-Wire bus OW_RPi: interface not found, answer
was
2012.11.07 08:03:35 1: OWX: 1-Wire bus OW_RPi: interface not found, answer
was
2012.11.07 08:03:35 1: OWX: 1-Wire bus OW_RPi: interface in COC_1 could not
be addressed
2012.11.07 08:03:36 3: OWTHERM: Device RPi_OW_Test defined.
2012.11.07 08:03:37 1: Including /var/log/fhem/fhem.save
2012.11.07 08:03:37 1: usb create starting
2012.11.07 08:03:39 3: Opening CUL device /dev/ttyAMA0
2012.11.07 08:03:39 3: Setting CUL baudrate to 38400
2012.11.07 08:03:39 3: CUL device opened
2012.11.07 08:03:39 1: usb create end
2012.11.07 08:03:39 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id:
fhem.pl 2085 2012-11-05 07:32:55Z rudolfkoenig $, pid 3081)
2012.11.07 08:03:46 3: OWX: Reset called with undefined interface
2012.11.07 08:03:46 3: OWX: Complex called with unknown interface on bus
OW_RPi
2012.11.07 08:03:46 3: OWX: Reset called with undefined interface
2012.11.07 08:03:46 3: OWX: Complex called with unknown interface on bus
OW_RPi
2012.11.07 08:03:46 3: OWX: Reset called with undefined interface
2012.11.07 08:03:46 3: OWX: Complex called with unknown interface on bus
OW_RPi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
I have a RPi, COC and FHEM running with 10 x FHT80B and 8 x DS18B20 on a
one wire bus.
Instead of using OWX, I use the Homematic emulation in the CULFW (set COC
raw OHo) - this works well but I still have the same problem as many with
the COC reporting unknown messages that appear to be coming from the one
wire bus.
Eventually I wrote a 'notify' that resets the COC and restarts FHEM
whenever an unidentified device was found:
1 Disable Autocreate
2 define LogUndef notify global:UNDEFINED.* set COC raw B00;;shutdown
restart
Not very pretty, but it works
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 2 define LogUndef notify global:UNDEFINED.* set COC raw B00;;shutdown
> restart
The COC does not implement B00, you have to reboot it via setting some GPIO
bits.
fhem> get CUL_0 raw
CUL_0 raw => ? (B00 is unknown) Use one of m C F i A Z O G M R T V W X e f l t u x
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
My COC appears to support it ! And it works, so thats OK.
2012.11.09 09:10:57 2: COC: unknown message ON
2012.11.09 09:10:57 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2085 2012-11-05 07:32:55Z rudolfkoenig $, pid 4871)
2012.11.09 09:10:56 1: Including /var/log/fhem/fhem.save
2012.11.09 09:10:54 3: set COC raw OHo
2012.11.09 09:10:54 3: COC: Possible commands: mBCFAZOGMRTVWXefltux
2012.11.09 09:10:51 3: COC device opened
2012.11.09 09:10:51 3: Setting COC baudrate to 38400
2012.11.09 09:10:51 3: Opening COC device /dev/ttyAMA0
2012.11.09 09:10:50 3: HOMEtablet: port 8086 opened
2012.11.09 09:10:50 3: WEBtablet: port 8085 opened
2012.11.09 09:10:50 3: WEBphone: port 8084 opened
2012.11.09 09:10:50 3: WEB: port 8083 opened
2012.11.09 09:10:50 3: telnetPort: port 7072 opened
2012.11.09 09:10:48 1: Including /etc/fhem.cfg
2012.11.09 09:10:45 0: Server shutdown
2012.11.09 09:10:45 3: set COC raw B00
Am Freitag, 9. November 2012 09:34:15 UTC schrieb Rudolf Koenig:
>
> > 2 define LogUndef notify global:UNDEFINED.* set COC raw B00;;shutdown
> > restart
>
> The COC does not implement B00, you have to reboot it via setting some
> GPIO
> bits.
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Erstaunlich.
Very strange - I have the same firmware version and it says
COC raw => ? (B is unknown) Use one of m C F A Z O G M R T V W X e f l t u
x
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
There must be something else involved beside the COC itself.
During the last days I updated my test system with RPi & COC nearly every
day by using the fhem update command.
What I can see from here is, that it takes only some hours for the COC for
getting mad. This behaviour is new. Before I had phases where the system
war running fine for at least a couple of days.
What I try to say: it seems to me that there's more than one contributor to
the problem, which might make it complex identifying the cause for all of
this.
BR
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Please post the version of the COC firmware obtained with get COC raw V
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
COC raw => V 1.47 CSM868
Am Freitag, 9. November 2012 11:17:02 UTC schrieb Prof. Dr. Peter A.
Henning:
>
> Please post the version of the COC firmware obtained with get COC raw V
>
> pah
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com