Hei Leute,
ich bin nur noch am lesen hier im Forum. Es gibt ja so unglaublich viel zu beachten, was mit wem und wie kompatibel ist, da blickt man leider nur sehr sehr schwer durch :(
Habe einen Raspberry Pi 512MB zuhause.
Jetzt habe ich den COC von busware.de bestellt in der "nur Funk" Version. Also ohne EEPROM ;)
Ich habe 9 ELRO Funksteckdosen die bisher anders geschaltet werden. Das klappt auch gut, nur sollen diese jetzt in FHEM!
Also ich möchte die ELRO AB440S ansteuern können, sowie mehrere Räume mit den MAX Heizungsthermostaten ausstatten.
Was ich verstanden habe:
Der COC kann zwar auf beiden Frequenzen funken, aber nicht im einen Modus funken und im anderen empfangen. Also ist er für einen Moment "Taub".
Vorerst möchte ich auf 433MHz nur senden. Das empfangen werde ich evtl. in Zukunft mit einem weiteren 433 Modul realisieren.
Die MAX Module haben keinen Temperatursensor, können also nur steuern, aber nicht "lesen". Schade.
Bedeutet, ich benötige noch Temperatursensoren für die einzelnen Räume. :/
Welche Version muss auf den COC geflasht werden?
Kann ich damit denn die ELROs steuern? Ich hoffe, denn das war der Kaufgrund.
Wenn der Server kurzzeitig "taub" ist, ist das kein Beinbruch. Denn die Temperatur ändert sich ja nicht so schnell. Und bis jetzt ist es das einzige was empfangen werden soll.
Leute, ich bin hilflos, wie ihr evtl. merkt. :(
Also noch mal in Kurzform:
Vorhanden:
- COC (und 433 MHz Modul als Sender und Empfänger für GPIOs, falls man damit was anfangen kann xD)
- Raspberry Pi mit 512mb Revision 2
- 9 ELROs
- 4 MAX Heizungsthermostate
Gewünschte Funktionen:
- ELROs schalten
- Temperatur lesen in jedem Raum
- Temperatur schalten nach gemessener Temp.
Möglich?
Was benötige ich noch?
Bitte helft mir! :)
Zitat von: mario92 schrieb am Di, 24 September 2013 13:53Vorerst möchte ich auf 433MHz nur senden. Das empfangen werde ich evtl. in Zukunft mit einem weiteren 433 Modul realisieren.
äh...
ich würde den COC für den Frequenzbereich 868MHz (Max, Homematic, FS20) verwenden und den 433MHz Bereich (den man heute eigentlich gar nicht mehr verwenden sollte) durch eine eigene Hardware abdecken.
(Nebenbei bemerkt: Baumarktsteckdosen und 433 MHz ist für mich am falschen Ende gespart. Aber das ist nur meine persönliche Meinung)
Okay,
danke für diese schnelle Rückmeldung!
Du sagtest 433 MHz mit eigener Hardware. Bedeutet, ich kann solche http://www.ebay.de/itm/433Mhz-RF-Transmitter-Module-and-Receiver-Link-Kit-for-Arduino-ARM-MCU-WL-/121177753231?pt=Wissenschaftliche_Geräte&hash=item1c36c1c68f (//www.ebay.de/itm/433Mhz-RF-Transmitter-Module-and-Receiver-Link-Kit-for-Arduino-ARM-MCU-WL-/121177753231?pt=Wissenschaftliche_Ger%C3%A4te&hash=item1c36c1c68f) Module per GPIO anschließen und mit FHEM verwenden?
Darf ich fragen, woher deine Abneigung kommt gegen diese Steckdosen? Denn ich finde sie klasse!
Ich nutze sie nur um Lampen (Stehlampen, Schreibtischlampen, Dekolampen) zu steuern. Ich wohne in einem Einfamilienhaus mit großem Grundstück und Nachbarn, für die ein Smartphone das neuste der Technik ist. Damit will ich sagen, mir funkt keiner dazwischen, die Last der Lampen ist gering. Und bis her hatte ich keine Probleme damit...!
Dennoch wäre ich bereit umzusteigen, auf die Teuren Dosen, dann möchte ich aber auch wissen, was sie so viel mehr besser macht..
LG und danke noch mal für die Rückmeldung!
Hallo Mario,
ZitatDie MAX Module haben keinen Temperatursensor, können also nur steuern, aber nicht "lesen". Schade.
Stimmt nicht ganz. Mit dem Temperaturscanner von John (http://forum.fhem.de/index.php?topic=11624.msg95735#msg95735) geben diese auch Temperaturwerte aus und die Temperatur kann mitgeloggt bzw. angezeigt werden. Und wenn etwas angezeigt wird, kannst Du dann auch damit mit einer Bedingung etwas Schalten ...
Für die ELRO Steckdosen findest Du hier (//www.fhemwiki.de/wiki/Intertechno_Code_Berechnung) ein paar Infos, ggf. noch einen CUL 433 MHz kaufen und loslegen ...
Gruß PeMue
Hallo zusammen,
meine MAX! Thermostatanttriebe geben eine SOLL und IST Temperatur an FHEM!
Nur am Wandthermostaten kann ich die Anzeige von SOLL auf IST wechseln.
Benötige ich dann noch das SKRIPT von John?
Gruß
pnewman
Hallo pnewman,
ich meine, die MAX Heizungsregler geben nur sehr selten eine Temperatur ab. Ich hatte das Skript von John nicht installiert, und da war teilweise stundenlang keine Isttemperaturen da sehen. Im Prinzip brauchst Du es nicht, aber wenn Du schöne Kurven willst, dann nimm es ...
Gruß PeMue
Okay, danke für die ganzen Antworten!
Jetzt habe ich das COC geflasht und wird auch erkennt, jedoch kann ich max nicht einbinden..
"attr COC rfmode MAX" gibt folgendes aus: COC: Mode MAX not supported
Unter dem COC steht unter Clients: :FS20:FHT:FHT8V:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX
Komme irgendwie nicht weiter :(
Hallo mario92,
hast Du dies auch alles durchgeführt?
sudo nano /etc/inittab
Löschen / Auskommentieren: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
Sodass diese so aussieht:
# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
Hier auch:
sudo nano /boot/cmdline.txt
- Wenn es dort vorhanden ist
Sodass diese so aussieht:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
sudo nano /etc/init.d/fhem
Alles zwischen Start) und Stop) ersetzen:
echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo "Starting fhem..."
$fhz $conf
RETVAL=$?
;;
STRG + O
STRG + X
(die fhem.cfg lässt sich auch im Browser bearbeiten http://192.168.178.30:8083/fhem (//192.168.178.30:8083/fhem) --> Edit files)
Zeile am Ende hinzufügen:
define COC CUL /dev/ttyAMA0@38400 1234
reboot
Bei Mir blinkt die LED am COC wenn er bereit ist.
Gruß
pnewman
Auf jeden Fall schon mal danke für diese Antwort!
Aber ich muss leider sagen, dass ich alles schon genau so hatte, wie du beschrieben hast. Exakt so. Und es funktioniert immer noch nicht.
Ist es egal, welche Version ich nehme zum Flashen? Habe mal irgendwo gelesen, dass HM und F20 oder so was nicht zusammen funktioniert, weil sie auch andere Hz haben, oder so was.. Da bin ich mir aber total unsicher..
Damit meine ich.. nicht das ich da was falsches habe.. :D
Wenn ich "attr COC rfmode MAX" eingebe, kommt "COC: Mode MAX not supported"...
Und wenn ich funksteckdosen steuern möchte (ELRO A440S), mit "define ELRO_11011_A IT FFFFF0FFFF FF F0" kommt auch nichts. Das ist doch der Hauscode 11111 , Unit A oder??
LG
Habe alles wie in den Dokus von Busware beschrieben eingerichtet. Damit es "einfacher" ist, nutzte ich als erstes das FHEM-Busware Image. Dann unter Xbian, Raspbmc, Wheezy.
In FHEM wird jetzt der COC angezeigt. Jedoch kann ich z.B. die Version mit "get COC version" nicht auslesen. Dabei und bei anderen bekomme ich "No Answer" zurück.. :/
Der COC blinkt nie! Nur beim Flashen. Weder beim Booten, noch im 1hz Takt, wie normalerweise. Nie.
Zum Thema Flashen..
Ich habe es mit unterschiedlichen Versionen (Link: http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/ (//sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/)) Versucht. Über die History habe ich folgende Versionen nacheinander ausprobiert: 1.52, 1.54, 1.55, 1.57 (Habe mir ein Shell Skript erstellt, welches die GPIOs Initialisiert und die neue Version lädt, FHEM beendet und dann Flasht)
FFHEM Version war beim Busware Image die 5.3-dev und wenn ich es selber installiert habe 5.4.
Ich bin natürlich alle Schritte durchgegangen, aber kein Erfolg. Habe alles was mir einfällt ausprobiert. Nichts klappt.
Wenn ich rfmode MAX hinzufügen möchte, kommt immer "MAX not supported".
Jetzt habe ich allerdings eine Vermutung:
Die COC Erweiterung wird nicht richtig als Serielle Schnittstelle/Maschine? in Linux erkannt, denn mit
sudo apt-get install minicom
minicom -D /dev/ttyAMA0 -b 38400
# nun V eingeben
V 1.52 CSM868
...
HB5510085414315 <-- Nachricht vom Temperatur/Feuchte-Sensor
klappt es nicht.
Wenn ich minicom aufrufe, steht unten drin "offline" und ich kann nichts tippen (auch nicht über CTRL+A...)
Woran kann es liegen??
Und warum blinkt da nichts?
LG und bitte hilft mir... Ich verzweifle.. :/
Hallo Mario,
ich habe mal verschiedene Fragen:
a.) Läuft fhem, wenn Du mit minicom versuchtst auf den COC zuzugreifen? Wenn ja, dann belegt fhem die serielle Schnittstelle und bei minicom geht nichts.
b.) Ich hatte mal ein ähnliches Problem mit CSM, wo einfach der MAX Teil gefehlt hat, siehe dieser Thread (http://forum.fhem.de/index.php?topic=13963.msg91280#msg91280). Hier dann ggf. selber compilieren (wenn Du es kannst, ich könnte es momentan noch nicht) oder z.B. Michael Gernoth fragen ...
c.) Wie sieht denn Dein Logfile aus? Wenn so etwas
2013.10.02 22:05:22 3: <name of CUL>: Possible commands: mBCFZiAGMRTVWXOefltuHxEcqkommt, dann wird der COC initialisiert, wenn da aber Z fehlt, dann könnte genau sein, dass die Firmware noch einen Fehler hat (siehe b.).
Gruß PeMue
Hei,
a) nein! FHEM ist gestoppt und trotzdem das Problem
b) das muss ich mir in Ruhe angucken, danke schon mal, aber erst mal muss die COC erkannt werden..
c) Nein, so was habe ich nicht.. Logfile:
2013.10.05 21:23:11 1: Including /opt/fhem/fhem.cfg
2013.10.05 21:23:12 3: telnetPort: port 7072 opened
2013.10.05 21:23:12 3: WEB: port 8083 opened
2013.10.05 21:23:12 3: WEBphone: port 8084 opened
2013.10.05 21:23:12 3: WEBtablet: port 8085 opened
2013.10.05 21:23:13 3: Opening COC device /dev/ttyAMA0
2013.10.05 21:23:13 3: Setting COC baudrate to 38400
2013.10.05 21:23:13 3: COC device opened
2013.10.05 21:23:22 1: Cannot init /dev/ttyAMA0, ignoring it
2013.10.05 21:23:22 1: Including ./log/fhem.save
2013.10.05 21:23:22 1: usb create starting
2013.10.05 21:23:24 3: Opening CUL device /dev/ttyAMA0
2013.10.05 21:23:24 3: Setting CUL baudrate to 38400
2013.10.05 21:23:24 3: CUL device opened
2013.10.05 21:23:24 1: usb create end
Hallo Mario,
wir hatten gerade Kontakt im Raspberry Pi Forum.
Ich verwendet folgende Konstellation:
CUL zum Ansteuern der MAX-Thermostate: (866 Mhz)
die liefern übrigens Temperatur, Sollwert und Istwert siehe:
Link (http://forum.fhem.de/index.php?topic=11624.msg68237#msg68237)
Da ich auch noch Feuchte messen will und hierzu Max nichts bietet setzte ich noch
einen HMS100TF ein (ebefalls 866 MHhz aber SlowRF)
Daher brauche ich einen weiteren Transeiver.
Ich habe mich für dem COC entschieden. (würde heute einen 2. CUL nehmen)
Dann möchte ich noch wie du, ein Funkschaltsteckdose ansteuern aus dem FS20 System (866 Mhz SlowRF)
Geht auch mit demselben COC.
Für CUL spricht übrigens, dass du diesen wiederverwenden kannst, wenn du den Controller wechselst.
(z.B. BeagleBone Black statt Raspi)
Was spricht gegen folgende Lösung in deinem Fall:
a. CUL 866 MHZ für die Max-Thermostate
b. CUL 433 MHZ für deine Steckdosen
John
Hei John,
ja, das denke ich mir gerade auch. Einfach zwei CULs...
Ich habe noch einen HP MicroServer N54L, mit Windows Home Server 2012 der 24/7 läuft. Würde doch auch gehen dort alles zu installieren, oder?
Wenn ich dieses Wochenende den COC nicht ans laufen bekomme, werde ich mir wohl zwei CULs bestellen.. Ist nur direkt wieder so teuer.. :(
LG
Zitata) nein! FHEM ist gestoppt und trotzdem das Problem
hm, wenn aber das Flashen funktioniert, sollte die serielle Schnittstelle beim Raspberry Pi freigeschaltet sein. Wie initialisiertst Du denn diesen in fhem, mit /dev/ttyAMA0@38400?
Ich habe für mein CSM am LCD Display folgendes Skript zum Flashen:
#!/bin/sh
# Vor dem Programmieren fhem stoppen!
# Reset an Pin 11 (GPIO17), Pin für Start Bootloader an Pin 18 (GPIO24)
# Optionen für avrdude siehe
# http://www.nongnu.org/avrdude/user-manual/avrdude_4.html
RESET_GPIO=17
BOOTSTART_GPIO=24
# nicht verwendeten Prozessor auskommentieren
#DEVICE=atmega324p
DEVICE=atmega1284p
if test -e "$1"; then
echo "calling CSM bootloader ..."
if test ! -d /sys/class/gpio/gpio$RESET_GPIO; then echo $RESET_GPIO > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio$BOOTSTART_GPIO; then echo $BOOTSTART_GPIO > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio$RESET_GPIO/direction
echo out > /sys/class/gpio/gpio$BOOTSTART_GPIO/direction
echo 0 > /sys/class/gpio/gpio$RESET_GPIO/value
echo 0 > /sys/class/gpio/gpio$BOOTSTART_GPIO/value
sleep 1
echo 1 > /sys/class/gpio/gpio$RESET_GPIO/value
sleep 1
echo 1 > /sys/class/gpio/gpio$BOOTSTART_GPIO/value
echo "programming CSM ..."
avrdude -p $DEVICE -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:$1
# nächste Zeile nur zum debuggen, normalerweise auskommentiert
# avrdude -p $DEVICE -P /dev/ttyAMA0 -b 38400 -c avr109 -U boot:r:-:i
else
echo "Error! No hex file given, or hex file could not be found!"
fiGruß PeMue
In deiner Log-Datei von oben:
Zitat2013.10.05 21:23:13 3: Opening COC device /dev/ttyAMA0
2013.10.05 21:23:13 3: Setting COC baudrate to 38400
2013.10.05 21:23:13 3: COC device opened
2013.10.05 21:23:22 1: Cannot init /dev/ttyAMA0, ignoring it
2013.10.05 21:23:22 1: Including ./log/fhem.save
2013.10.05 21:23:22 1: usb create starting
2013.10.05 21:23:24 3: Opening CUL device /dev/ttyAMA0
Du verwendest sowohl für COC wie auch für CUL dasselbe device /dev/ttyAMA0.
Bei mir ist der COC über das device /dev/ttyAMA0 verbunden.
Nachfolgend meine Configuration mit COC und CUL
Vielleicht hilft das weiter.
define COC CUL /dev/ttyAMA0@38400 1234
attr COC room System
attr COC verbose 4
define CUL CUL /dev/ttyACM0@38400 0000
attr CUL rfmode MAX
attr CUL room System
attr CUL verbose 4
define CULMAX0 CUL_MAX 123456
attr CULMAX0 room System
attr CULMAX0 verbose 4Beende mal FHEM und versuch dich via Minicom zu verbinden:
Zitatminicom -D /dev/ttyAMA0 -b 38400
John
Danke erst mal an alle! Schön das sich so viele die Zeit nehmen!!
Also erst mal sieht meine fhem.cfg Datei so aus:
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath . # where our FHEM directory is
attr global statefile ./log/fhem.save # where to save the state of the devices
attr global verbose 3 # "normal" verbosity (min 1, max 5)
define telnetPort telnet 7072 global # our TCP/IP port
define WEB FHEMWEB 8083 global
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 autosave
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink
attr autocreate weblink_room Plots
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
# If the above notify did not helped, then you probably have to enable some of
# the following lines. Verify first that /dev/xxx ist correct.
#define FHZ FHZ /dev/USB0
#define CUL CUL /dev/ttyACM0@9600 1234
#attr CUL rfmode HomeMatic
#define EUL TCM 310 /dev/ttyACM0@57600
#define BscBor TCM 120 /dev/ttyUSB0@9600
#define BscSmartConnect TCM 310 /dev/ttyUSB0@57600
define COC CUL /dev/ttyAMA0@38400 1234
Wenn ich das richtig sehe, wird doch nirgends ein CUL definiert, oder? Ich meine ist ja auch richtig, ich habe ja nur einen COC.
Zum Thema Flashen.
Ich habe folgendes Shell Skript:
echo "calling COC bootloader..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value
echo "Flaschen...."
avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.radio_only.hex
Damit klappt auch alles! Ich beende davor selbstverständlich FHEM!
Es kommt das als Ausgabe:
sh coc_update.sh
calling COC bootloader...
Flaschen....
Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
Software Version = 0.8; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.
Programmer supports the following devices:
Device code: 0x46
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is 1426130024 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "COC.radio_only.hex"
avrdude: input file COC.radio_only.hex auto detected as raw binary
avrdude: writing flash (60924 bytes):
Writing | ################################################## | 100% 19.21s
avrdude: 60924 bytes of flash written
avrdude: verifying flash memory against COC.radio_only.hex:
avrdude: load data flash data from input file COC.radio_only.hex:
avrdude: input file COC.radio_only.hex auto detected as raw binary
avrdude: input file COC.radio_only.hex contains 60924 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 16.48s
avrdude: verifying ...
avrdude: 60924 bytes of flash verified
avrdude done. Thank you.
So.
Habe frisch geflasht, FHEM ist noch beendet, dann habe ich "minicom -D /dev/ttyAMA0 -b 38400" ausgeführt, jedoch steht wieder unten rechts offline und ich kann nur CTRL+A und dann z.B. Z drücken für Hilfe, sowie die anderen dann angezeigten Buchstaben. Leider kann ich nicht einfach "run V" eingeben. :/
Habe dann über die FHEM Seite die Definitionen von John in die fhem.cfg angehangen. FHEM meldete:
COC: unknown attribute verbose, choose one of room group comment alias eventMap userReadings do_not_notify:1,0 dummy:1,0 showtime:1,0 model:CUL,CUN,CUR loglevel:0,1,2,3,4,5,6 sendpool addvaltrigger rfmode:SlowRF,HomeMatic,MAX hmId hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger or use attr global userattr verbose CUL: Mode MAX not supported CUL: unknown attribute verbose, choose one of room group comment alias eventMap userReadings do_not_notify:1,0 dummy:1,0 showtime:1,0 model:CUL,CUN,CUR loglevel:0,1,2,3,4,5,6 sendpool addvaltrigger rfmode:SlowRF,HomeMatic,MAX hmId hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger or use attr global userattr verbose CULMAX0: unknown attribute verbose, choose one of room group comment alias eventMap userReadings IODev do_not_notify:1,0 ignore:0,1 showtime:1,0 loglevel:0,1,2,3,4,5,6 event-on-change-reading event-on-update-reading event-min-interval stateFormat or use attr global userattr verbose
Jetzt versuche ich mit dem Shell-Script von PeMue zu flashen! (flashen.sh)
root@raspberrypi:~# /etc/init.d/fhem stop
Stopping fhem...
root@raspberrypi:~# sh flashen.sh COC.radio_only.hex
calling CSM bootloader ...
programming CSM ...
Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
root@raspberrypi:~#
Ach menno. Was mache ich denn falsch... :(
Danke noch mal für eure Bemühungen, Leute!! :) :)
_________________________________________________________________________________________________________________________
Hier sind noch weitere Daten, falls Sie wichtig sind:
"hexdump -C /sys/bus/i2c/devices/0-0050/eeprom" liefert:
00000000 43 4f 43 20 56 31 2e 31 20 52 41 44 49 4f 5f 4f |COC V1.1 RADIO_O|
00000010 4e 4c 59 20 32 30 31 33 2d 30 38 2d 32 36 0a ff |NLY 2013-08-26..|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000100
/etc/inittab
# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $
# The default runlevel.
id:2:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
# <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3
#Spawn a getty on Raspberry Pi serial line
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
/boot/cmdline.txt
# Original:
# dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
/etc/init.d/fhem
#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert
### BEGIN INIT INFO
# Provides: fhem.pl
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: FHEM server
### END INIT INFO
set -e
cd /opt/fhem
port=7072
case "$1" in
'start')
echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo "Starting fhem..."
perl fhem.pl fhem.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem..."
perl fhem.pl $port "shutdown"
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem is not running"
else
echo "fhem is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
So. Ich denke erst ein mal genug für einen Samstagabend.. :D -nacht.
LG
ZitatHabe frisch geflasht, FHEM ist noch beendet, dann habe ich "minicom -D /dev/ttyAMA0 -b 38400" ausgeführt, jedoch steht wieder unten rechts offline und ich kann nur CTRL+A und dann z.B. Z drücken für Hilfe, sowie die anderen dann angezeigten Buchstaben. Leider kann ich nicht einfach "run V" eingeben. :/
nicht "run V" sondern nur "V"+Enter.
(siehe Anhang / see attachement)
Die Schnittstelle funktioniert, sonst könntest du nicht erfolgreich flashen.
Wenn man einen unbekannten Befehl eingibt erscheint:
Zitata
? (a is unknown) Use one of m C F i A Z G M R T V W X e f l t u x
John
Klappt nicht.
Habe mit CTRL+A und E das lokale Echo eingeschaltet. jetzt kann ich zwar schreiben, aber er reagiert nicht, als wenn ich nicht Tippe..
Bei ausgeschaltetem lokalen Echo kann ich nicht schreiben.
Evtl. doch ein Flash Problem??
Dauert es eigl. immer 20 Sekunden bei den letzten beiden Vorgängen? Bei Auszügen im Internet sehe ich meistens eher 10S.. :D
Ich schick dir hiermit meine COC_154.HEX.
Auch ich verwende ebenso wie du die Version Radio_Only.
Die funktioniert bei mir problemlos.
John
Es scheint zu klappen!!
minicom liefert: V 1.54 CSM868
Flashen dauerte auch nur 5 Sekunden :)
Werde mich gleich mal FHEM widmen. Danke auf jeden Fall!!! Danke!
Hei Leute,
es scheint echt zu klappen :) :) Hammer!!
Zwei von 4 Thermostaten lassen sich ändern. Zwei andere nicht:
2013-10-06_15:05:16 MAX_07bb25 mode: manual
2013-10-06_15:05:16 MAX_07bb25 battery: ok
2013-10-06_15:05:16 MAX_07bb25 desiredTemperature: 18.5
2013-10-06_15:05:16 MAX_07bb25 valveposition: 6
2013-10-06_15:05:16 MAX_07bb25 18.5 °C
2013-10-06_15:05:53 MAX_07bb25 desiredTemperature 18.0
2013-10-06_15:06:12 MAX_07bb25 mode: manual
2013-10-06_15:06:12 MAX_07bb25 battery: ok
2013-10-06_15:06:12 MAX_07bb25 desiredTemperature: 18.5
2013-10-06_15:06:12 MAX_07bb25 valveposition: 6
2013-10-06_15:06:12 MAX_07bb25 temperature: 20.3
2013-10-06_15:06:12 MAX_07bb25 18.5 °C
2013-10-06_15:06:51 MAX_07bb25 desiredTemperature 18.0
2013-10-06_15:06:54 MAX_07bb25 desiredTemperature 18.0
2013-10-06_15:07:58 MAX_07bb25 desiredTemperature 18.0
2013-10-06_15:08:12 MAX_07bb25 mode: manual
2013-10-06_15:08:12 MAX_07bb25 battery: ok
2013-10-06_15:08:12 MAX_07bb25 desiredTemperature: 21.0
2013-10-06_15:08:12 MAX_07bb25 valveposition: 75
2013-10-06_15:08:12 MAX_07bb25 temperature: 20.4
2013-10-06_15:08:12 MAX_07bb25 21.0 °C
Mode Manuel?
Wie richte ich jetzt auf dem selben COC die Steuerung von Intertechno (ELRO) ein? Er muss doch irgendwie dann den Modus switchen, oder? LG
Hallo Mario,
hier mal wie Ich vorgehe.
Den COC in Anlernmodus bringen
set CULMAX0 pairmode 30
In fhem eingeben, dann das Gerät in Anlernmodus bringen.
Bei MAX! den BOOST knopf drücken bis die 30sec anlaufen!
Meine Geräte zählen dann herunter, kommen aber nur bis 27. Wenn sie bei mir bis 0 kommen sind sie nicht richtig angelernt!
Wenn Sie nicht richtig angelernt sind mache Ich einen reset und fange von vorne an.
Ich habe festgestellt, dass ich zwischen durch eine Pause machen muss, sonst passiert es mir das die Geräte nicht richtig angelernt werden.
Danach benenne ich sie in der fhem.cfg um durch
rename MAX_xxxx HZ_Buero zb.
Gruß
pnewman
Alles klar, dat hat schon mal geklappt! Aber wie kann ich jetzt zusätzlich Intertechno einbinden??
Dazu hier ein neues Thema:
http://forum.fhem.de/index.php?t=msg&goto=98182&rid=2812#msg_98182 (//forum.fhem.de/index.php?t=msg&goto=98182&rid=2812#msg_98182)
Hi,
ich habe exakt das gleich Problem wie oben beschrieben und bekomme "no answer" seit dem Update. LED blinkt nicht (außer beim flashen).
Voraussetzung: RaspPi v2 + COC (inkl. RTC; OneWire) + Image von busware
Kann mir jemand eine funktionierende Firmware bereitstellen? Habe bereits mehrere Versionen probiert. Minicom steht bei mir auch auf offline.
Grüße Ronny
Dann hast du das selbe Problem wie ich. Leider habe ich nicht die passende Firmware..
Ich würde sagen wir sollten diesbezüglich mal Busware kontaktieren, denn das kann es ja nicht sein.
Ich kann deren Software nur mit der Firmware von jemandem aus dem Forum nutzen und nicht mit der von denen bereitgestellten??
Ich habe ihnen schon mal geschrieben und bekam die Antwort:
ZitatHallo!
COC werden programmiert und getestet ausgeliefert, daher ist zur Inbetriebnahme kein weiteres Flashen notwendig.
Wie Sie FHEM einrichten klären Sie bitte in den entsprechenden Foren oder lesen hilfreiche Dokumentationen.
Sollte Sie das überfordern nutzen Sie bitte Ihr 14tägiges Rückgaberecht.
Viel Erfolg!
Daraufhin bat ich um funktionierende Firmware. Jedoch habe ich seit dem nichts mehr gehört (2. Okt). :(
Super Support muss man sagen... -.-
Hi,
also ich hatte meinen COC kurzzeitig zum testen auf einem RaspPi v1, mit gleichem Fehlerbild -> also wieder auf den aktuellen RaspPi. Dann hatte ich aufgrund der Foreneinträge versucht eine radio_only zu flashen, was bei mir fehlgeschlagen ist:
root@raspberrypi:/tmp# ls
COC.radio_only_1.54.hex
root@raspberrypi:/tmp# echo "calling COC bootloader..."
calling COC bootloader...
root@raspberrypi:/tmp# if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
root@raspberrypi:/tmp# if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
root@raspberrypi:/tmp# echo out > /sys/class/gpio/gpio17/direction
root@raspberrypi:/tmp# echo out > /sys/class/gpio/gpio18/direction
root@raspberrypi:/tmp# echo 0 > /sys/class/gpio/gpio18/value
root@raspberrypi:/tmp# echo 0 > /sys/class/gpio/gpio17/value
root@raspberrypi:/tmp# sleep 1
root@raspberrypi:/tmp# echo 1 > /sys/class/gpio/gpio17/value
root@raspberrypi:/tmp# sleep 1
root@raspberrypi:/tmp# echo 1 > /sys/class/gpio/gpio18/value
root@raspberrypi:/tmp# avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.radio_only.hex
Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
Software Version = 0.8; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.
Programmer supports the following devices:
Device code: 0x46
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "COC.radio_only.hex"
avrdude: error opening COC.radio_only.hex: No such file or directory
avrdude: input file COC.radio_only.hex auto detected as invalid format
avrdude: can't open input file COC.radio_only.hex: No such file or directory
avrdude: read from file 'COC.radio_only.hex' failed
avrdude done. Thank you.
Danach habe ich, weil das nicht geklappt hat, noch mal die V1.55 full aus dem trunk geflasht:
root@raspberrypi:/tmp# echo "calling COC bootloader..."
calling COC bootloader...
root@raspberrypi:/tmp# if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
root@raspberrypi:/tmp# if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
root@raspberrypi:/tmp# echo out > /sys/class/gpio/gpio17/direction
root@raspberrypi:/tmp# echo out > /sys/class/gpio/gpio18/direction
root@raspberrypi:/tmp# echo 0 > /sys/class/gpio/gpio18/value
root@raspberrypi:/tmp# echo 0 > /sys/class/gpio/gpio17/value
root@raspberrypi:/tmp# sleep 1
root@raspberrypi:/tmp# echo 1 > /sys/class/gpio/gpio17/value
root@raspberrypi:/tmp# sleep 1
root@raspberrypi:/tmp# echo 1 > /sys/class/gpio/gpio18/value
root@raspberrypi:/tmp# avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.hex
Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
Software Version = 0.8; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.
Programmer supports the following devices:
Device code: 0x46
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "COC.hex"
avrdude: input file COC.hex auto detected as Intel Hex
avrdude: writing flash (21020 bytes):
Writing | ################################################## | 100% 6.64s
avrdude: 21020 bytes of flash written
avrdude: verifying flash memory against COC.hex:
avrdude: load data flash data from input file COC.hex:
avrdude: input file COC.hex auto detected as Intel Hex
avrdude: input file COC.hex contains 21020 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 5.73s
avrdude: verifying ...
avrdude: 21020 bytes of flash verified
avrdude done. Thank you.
Nun lebt er wieder! Ich vermute das folgendes nicht ganz unwichtig war:
avrdude: erasing chip
avrdude: reading input file "COC.radio_only.hex"
avrdude: error opening COC.radio_only.hex: No such file or directory
Ist aber nur die Vermutung eines Laien! Ich habe die beiden Files die ich /versucht/ geflasht habe mal angehangen, vielleicht hilft es auch anderen als Workaround. Grundlage hier ist das Image von busware.
EDIT:
Zusammgefasst: Ich habe jetzt noch mal probiert. Flasht beim ersten mal eine hex- file, die nicht existiert. avrdude löscht den Speicher und springt dann raus, da die hex- file nicht gefunden werden kann. Danach die COC 1.55 flashen, dann sollte es gut sein.
echo "calling COC bootloader..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value
avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.radio_only.hex
echo "calling COC bootloader..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value
avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.hex
Sorry für den langen Beitrag, ich hoffe ich kann anderen damit helfen ihre Hausautomatisierung wieder zum laufen zu bekommen.
Grüße Ronny
Hallo,
leider habe ich ein ähnliches Problem. Habe versucht die COC zu flashen, kommend von Version 1.47 auf die aktuellste - Kein Lebenszeichen mehr. Die LED blinkt nicht. Das Flashen ist allerdings noch möglich.
Hardware: Raspi V2 / COC v1.1
Was mich stutzig macht, sind die Ausgaben im fhem-LOG:
2013.10.09 10:14:49 3: Opening COC device /dev/ttyAMA0
2013.10.09 10:14:49 3: Setting COC baudrate to 38400
2013.10.09 10:14:49 3: COC device opened
2013.10.09 10:14:58 1: Cannot init /dev/ttyAMA0, ignoring it
2013.10.09 10:14:58 2: COC: Mode HomeMatic not supported
2013.10.09 10:14:58 3: COC: Mode HomeMatic not supported
---
2013.10.09 10:15:01 1: Including /var/log/fhem/fhem.save
2013.10.09 10:15:01 1: usb create starting
2013.10.09 10:15:02 3: Opening CUL device /dev/ttyAMA0
2013.10.09 10:15:02 3: Setting CUL baudrate to 38400
2013.10.09 10:15:02 3: CUL device opened
2013.10.09 10:15:03 3: Opening TCM310 device /dev/ttyAMA0
2013.10.09 10:15:03 3: Setting TCM310 baudrate to 57600
2013.10.09 10:15:03 3: TCM310 device opened
2013.10.09 10:15:03 1: usb create end
2013.10.09 10:15:03 0: Server started with 104 defined entities (version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $, os linux, user fhem, pid 2172)
Ein Device TCM310 kenne ich nicht und ist auch in der Config nicht definiert.
Zudem habe ich eine Anleitung zum Flashen im Internet gefunden (Quelle: http://wolf-u.li/4782/installation-des-busware-coc-auf-dem-raspberry-pi-fuer-die-nutzung-mit-fhem/ (//wolf-u.li/4782/installation-des-busware-coc-auf-dem-raspberry-pi-fuer-die-nutzung-mit-fhem/)), an die ich mich anfangs gehalten habe.
Dann ist mir folgendes aufgefallen:
Hier ein Ausschnitt, bereits auf meine Version angepasst:
wget "http://culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/Devices/COC/COC.hex?revision=HEAD (//culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/Devices/COC/COC.hex?revision=HEAD)" -O COC.hex
Auf der Busware-Seite sieht der Link zur Firmware wie folgt aus:
http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/COC.hex?format=raw (//sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/COC.hex?format=raw)
Tja, beide liefern andere Ergebnisse (Dateigröße) - Welche ist richtig?
Die hier von Ronny gepostete funktioniert leider auch nicht.
Auf Version 1.47, die ja mal funktionierte, kann ich nicht zurück - ich finde sie nicht. Ansonsten habe ich schon diverse Versionen versucht - ohne Erfolg.
Ich hoffe, dass hier jemand noch Ideen dazu hat...
Vielen Dank,
Dirk
Hi,
wollte gerade schon antworten... Nach dem flashen von 1.55 hatte ich dann wieder gleiches Fehlerbild. Die angehängte Datei erweckt meine COC zumindest wieder zum leben!! Ich werde nun weiter probieren..
Grüße Ronny
EDIT:
Danach flash der v1.52 -> COC tot
Hallo Ronny,
kurze Frage, welche COC hast du? Die mit OneWire oder ohne, also coc.hex oder coc_radio_only.hex?
Danke,
Dirk
Hi,
COC + OneWire
Was mir aufgefallen ist: beim hex- file, welches meinen COC wieder zum leben erweckt steht beim flashen
avrdude: input file COC_154.hex auto detected as Intel Hex
bei der anderen Firmware steht
avrdude: input file COC.hex auto detected as raw binary
Grüße
Hi Ronny,
siehe da, habe deine Version genommen und es funzt wieder.
-> Die 1.54 kann ich auf sourceforge nicht finden???
Vielen Dank!
Hi,
ich kann sie dort auch nicht finden, genauso wenig wie die 1.49... Ich nehme jetzt auch die 1.54, es schein damit erst mal wieder alles zu laufen.
Grüße Ronny
Hallo,
ich habe erstmal dieses Betriebsystem
2013-09-10-wheezy-raspbian
von hier
http://www.raspberrypi.org/downloads
installiert.
dann die Vorbereitungen wie in Post
Sa, 28 September 2013 19:38
dann das COC geflasht nach dieser Anleitung:
http://files.busware.de/RPi/README.kernel
danach lief alles bei mir.
Vorher hatte ich ebenfalls probleme mit dem COC-flashen.
Gruß
pnewman
Guten Morgen,
nachdem ich gestern noch extrem lange herumgedoktort habe, bin ich nicht weiter gekommen. So viel kann ich sagen, dass alle FWs für die COC, nach der 1.54 nicht laufen. Nun ja, genau so eine benötige ich, wegen des Burst-Modes (HM_LC_SW4_BA_PCB).
Was mir bei dem ganzen Flashen aufgefallen ist, dass bei den Versionen < 1.55 die Flashgröße erheblich geringer als die Dateigröße ist. Bei der 1.54 - 15 zu 42. Bei den höheren FWs kann ich das so nicht feststellen. Ob das wichtig ist, keine Ahnung...
-rwxr-xr-x 1 root root 42752 Okt 10 10:01 COC_154.hex
avrdude: 15188 bytes of flash written
Die große GFrage ist, warum es anscheinend bei einigen COC-Erweiterungen nicht funktioniert.
Gruß,
Dirk
Zitat von: super_dau am 10 Oktober 2013, 12:36:58
dass bei den Versionen < 1.55 die Flashgröße erheblich geringer als die Dateigröße ist
Durch zufall gerade über beide Postings hier gestoßen. Schon einmal das hier (http://forum.fhem.de/index.php/topic,14427.msg99900.html#msg99900) gelesen? Es scheint wohl so zu sein das:
Zitat von: JoWiemann am 14 Oktober 2013, 20:42:18
Lädt man mit wget ohne die Ergänzung format=raw das hex-file runter, dann erhält man einen html-Header als Vorspann, der dann mitgeflasht wird und das gibt einfach murks.
Ich lade jetzt mit
sudo wget http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/COC.hex?format=raw -O /tmp/COC.hex
das hex-file herunter und schon funktionierts wieder.
Danke für den Hinweis.
Jetzt habe ich es noch nicht versucht und frage mich auch, wieso ich es versuchen sollte. Es funktioniert bei mir ja alles.
Was wurde geändert in den neueren Versionen nach 1.52?
LG
Ich benötige eine neuere Version als die 1.54! Gibt es was neues?
Klappen neuere denn inzwischen?
gibt es nicht mittlerweile die 1.57?
Siehe die Passende Webside .. dort steht auch ein changelog ;o)
Ich hatte auch Probleme beim Flashen. Habe das jetzt bei 3 Geräten nach folgender Anleitung durchgeführt:
http://www.fhemwiki.de/wiki/COC_am_Raspberry_Pi_flashen
Das hat jetzt bei jedem der Geräte (unterschiedliche Bauzeiten) erfolgreich funktioniert. Vielleicht hilft es...