Hallo Leute,
hab zwei Probleme:
1. Ich habe mir einen zweiten HMLAN zwecks Reichweitenvergrößerung zugelegt - an diesen habe ich ein Wandthermostat mittels set HMLAN2 hmPairForSec 600 angemeldet - soweit so gut.
Jetzt habe ich aber des öfteren das Problem, dass bei den ANDEREN Geräten beim IODev der HMLAN2 statt des HMLAN1 steht???
2. Mein HM-LC-Dim1L-Pl-2 Funk-Zwischenstecker-Dimmaktor 1fach Phasenanschnitt verweigert völlig den Dienst. Er lässt sich gar nicht mehr ansprechen???? Ich habe dann einen zweiten gepairt (und extra den HMLAN2 rausgezogen) - und der neue funktioniert ebenfalls nicht ganz unten in der fhem.conf). Woran kann das liegen????
Hier meine fhem.conf
>>>
attr global autoload_undefined_devices 1
attr global logfile /var/log/fhem/fhem-%Y-%m.log
attr global modpath /usr/share/fhem
attr global motd none
attr global sendStatistics onUpdate
attr global statefile /var/log/fhem/fhem.save
attr global uniqueID /usr/share/fhem/FHEM/FhemUtils/uniqueID
attr global userattr devStateIcon devStateStyle fm_fav fm_groups fm_name fm_order fm_type fm_view icon sortby webCmd
attr global verbose 4
# attr global sendStatistics manually
#
# pgm2 / autocreate configfile. Take a look at the other examples for more.
#
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 /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
# 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 HMLAN1 HMLAN 192.168.178.54:1000
attr HMLAN1 hmId 1E9DA6
attr HMLAN1 hmLanQlen 1_min
# 1E9DA6 = 2006438 - siehe http://www.arndt-bruenner.de/mathe/scripts/Zahlensysteme.htm
define HMLAN2 HMLAN 192.168.178.63:1000
attr HMLAN2 hmId 2DDFE6
attr HMLAN2 hmLanQlen 1_min
# 2DDFE6= 3006438
define Wetter weblink iframe http://www.wetteronline.de/cgi-bin/hpweather?PLZ=55442
define telnetPort telnet 7072 global
# Bewegungsmelder
define BewegMeld_Wintergarten_01 CUL_HM 1B0DA4
attr BewegMeld_Wintergarten_01 .devInfo 810100
attr BewegMeld_Wintergarten_01 .stc 81
attr BewegMeld_Wintergarten_01 autoReadReg 4_reqStatus
attr BewegMeld_Wintergarten_01 expert 2_full
attr BewegMeld_Wintergarten_01 firmware 1.0
attr BewegMeld_Wintergarten_01 model HM-SEC-MDIR
attr BewegMeld_Wintergarten_01 peerIDs
attr BewegMeld_Wintergarten_01 room Wintergarten
attr BewegMeld_Wintergarten_01 serialNr JEQ0091643
attr BewegMeld_Wintergarten_01 subType motionDetector
define FileLog_BewegMeld_Wintergarten_01 FileLog /var/log/fhem/BewegMeld_Wintergarten_01-%Y.log BewegMeld_Wintergarten_01
attr FileLog_BewegMeld_Wintergarten_01 logtype text
attr FileLog_BewegMeld_Wintergarten_01 room Wintergarten
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector room Wintergarten
define FileLog_ActionDetector FileLog /var/log/fhem/ActionDetector-%Y.log ActionDetector
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room Wintergarten
#Steckdose
define fd_wintergarten_01 CUL_HM 1D8B7A
attr fd_wintergarten_01 .devInfo 010100
attr fd_wintergarten_01 .stc 20
attr fd_wintergarten_01 IODev HMLAN1
attr fd_wintergarten_01 autoReadReg 4_reqStatus
attr fd_wintergarten_01 expert 2_full
attr fd_wintergarten_01 firmware 2.2
attr fd_wintergarten_01 model HM-LC-Dim1L-Pl-2
attr fd_wintergarten_01 peerIDs 00000000,
attr fd_wintergarten_01 room Wintergarten
attr fd_wintergarten_01 serialNr JEQ0567573
attr fd_wintergarten_01 subType dimmer
attr fd_wintergarten_01 webCmd toggle:on:off:up:down:statusRequest
define FileLog_fd_wintergarten_01 FileLog /var/log/fhem/fd_wintergarten_01-%Y.log fd_wintergarten_01
attr FileLog_fd_wintergarten_01 logtype text
attr FileLog_fd_wintergarten_01 room Wintergarten
define BewegMeld_Wintergarten_01Notify notify BewegMeld_Wintergarten_01:motion.* {if(ReadingsVal("BewegMeld_Wintergarten_01","brightness","100")<40){fhem "set fd_wintergarten_01 on-for-timer 300"}}
attr BewegMeld_Wintergarten_01Notify room Wintergarten
define CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 CUL_HM 1D8B73
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 .devInfo 010100
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 .stc 20
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 firmware 2.2
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 model HM-LC-Dim1L-Pl-2
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 room CUL_HM
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 serialNr JEQ0567581
attr CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 subType dimmer
define FileLog_CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 FileLog /var/log/fhem/CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73-%Y.log CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73
attr FileLog_CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 logtype text
attr FileLog_CUL_HM_HM_LC_Dim1L_Pl_2_1D8B73 room CUL_HM
<<<
Hallo,
auch wenn ich dir nicht viel helfen kann da ich noch recht wenig HM-Geräte habe aber ...
Zitatdass bei den ANDEREN Geräten beim IODev der HMLAN2 statt des HMLAN1 steht
Hast du das IODev von Hand gesetzt?
Soweit ich weiss nimmt FHEM bei Geräten an denen kein IODev gesetzt wurde immer das zuletzt definierte Device - bei dir dann HMLAN2.
Versuch doch mal bei ALLEN! Geräten manuell das von dir gewünschte IODev zuzuordnen - und dann auf save config klicken.
Ich kann dir nur von mir sagen das ich bei meinen FS20-Geräten für ALLE! Geräte das IODev gesetzt habe.
Ich musste dann nur noch mal kurz en Speicher der 4 CUNO leer machen und seither habe ich keine Probleme mehr mit meinen FHT und den FS20-Geräten.
Evtl. kann es bei dem einen oder anderen Gerät sinnlos sein ein IODev zu setzen - speziell bei einem Bewegungsmelder.
Aber FHEM stört sich nicht dran.
Ich hoffe mal das es sich nicht störend auswirkt aber weniger als sowieso schon bei dir geht kann ja dann fast nichtmehr gehen.
Grüsse
Hallo Puschel74,
das Problem wird skuril:
Die Idee die IODev manuel umzustellen ist mir auch gekommen - hab ich gemacht, außerdem HMLAN2 mal vom Netz genommen, HMLAN1 kurz vom Strom genommen, wieder gepairt, ... das ganze zirka 20 mal jetzt gehts (teilweise) wieder.
Warum teilweise: Je nachdem was für eine Glühbirne! ich in der Lampe habe die über die Dimmsteckdose geschaltet wird, funktionierts - oder eben nicht!
a) mit einer LED Glühbirne: funktioniert nicht/ nur sehr sporadisch - und das obwohl genau diese Kombination (HMLAN1 + Dimmsteckdose + LED Glühbirne) im letzten dreiviertel Jahr völlig problemlos gelaufen ist
b) mit Standardglühbirne in der Fassung der Lampe in der zuvor die LED Lampe (dimmbar) war - absolut kein Problem
????
Kann sich da jemand einen Reim darauf machen. Ich könnte es ja noch verstehen, wenn der Setup mit LED Lampen generell nicht funktioniert (vielleicht zu geringer Widerstand oder was weiss ich was ...) - aber dass es bisher funktioniert hat, und jetzt eben nicht mehr - das ist mir ein Rätsel
Sascha
Hallo Sascha,
das attribut IODev hast du also durchgängig gesetzt - in allen devices (nicht in channels -sollte ich evtl verbieten)
kannst du einmal logs ziehen? Nach
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
verbose bei beiden HMLAN setzen.
Wenn sich das Device garnicht mehr meldet schalte einmal den Strom aus und ein (alles loggen) und drücke einmal anlernen
Gruss Martin
@martin: rudi hat inzwischen in AssignIoPort eingebaut das man optional ein iodev vorschlagen kann das statt dem letzten definierten verwendet wird.
damit kann man z.b. in die UNDEFINED meldung bei einem unbekannten device das iodev parameter mit geben und dann im define im AssignIoPort verwenden und aus dem DEF entfernen.
damit kann man sich glaube ich einige der probleme mit falsch gesetztem IODev bei neu angelegten devices sparen. vielleicht passt das für hm ja auch.
der thread dazu ist hier:http://forum.fhem.de/index.php/topic,16676.0.html (http://forum.fhem.de/index.php/topic,16676.0.html)
gruss
andre
Hallo Sascha,
Ohne den detaillierten Aufbau zu kennen vermute ich, dass deine Glühbirne deine Elektronik über den Glühfaden mit dem Nulleiter versorgt, da im ausgeschalteten Zustand dieser sehr niederohmig ist.
LEDs haben hingegen eine exponentielle Kennlinie. D.h. Sie sind im ausgeschalteten Zustand sehr hochohmig und können daher den Nulleiter "nicht durchlassen" (Die Elektrotechniker unter uns mögen mir meine Wortwahl vergeben) :)
Dieses Verhalten hätte ich aber eher von einem Unterputzschalter/Dimmer erwartet aber nicht, wie von dir beschrieben, von einem in der normalen Steckdose zwischengeschalteten Device.
Poste doch mal den Aufbau bzw. das Manual bzw. den Typ des Geräts.
Gruß
Sailor
Gesendet von meinem iPhone mit Tapatalk (http://tapatalk.com/m?id=1)
Hallo Andre,
interessanter Ansatz. Lass mich verstehen was passieren soll:
ohne proposed:
. fhem sucht das erste kompatible IOdevice und trägt es bei der Definition ein
. der User kann ein setzen per IOdev
negativ: wenn ein passendes IO device zum Zeitpunkt der definition nicht existiert wird nichts eingetragen - senden nicht möglich
==> könnte ich abfangen ... gute Idee!
mit proposed
falls proposed mitgegeben wird, wird es gnadenlos eingetragen(so lange es existiert). Beim Aufruf muss man also aufpassen, ob der User eins definiert hat, damit man es nicht tötet.
Leider wird es gleich ins attribut geschrieben - wäre nicht notwendig gewesen.
User mit mehreren IO devices bring dies nichts - die müssen/sollten selbst wählen, welches IODev zu welchem Device gehören soll.
sollte AssignIoPort nicht nach prio vorgehen
1) IODev aus attribut
2) proposed
3) first suitable
-> attribute nie setzen - sonst muss man es extern abfangen - wäre schade, wenn es jeder extra machen muss.
Beim grep durch den Code scheint OWDEVICE als einziger eine Abfrage dabei zu haben - aber war nur ein quickGrep.... proposed nutzt aktuell keiner.
Du willst also ein Attribut vergeben, dass in Autocreate gesetzt wird und dann in alle Devices einer Familie eingetragen wird.
Bin ich auf dem falschen Dampfer?
Gruss Martin
ich bin gerade dabei es in die ganzen jeelink module einzubauen. zur zeit nutzt es vermutlich tatsächlich noch keiner.
wie im thread schon beschrieben habe ich dort das problem das pro jeelink je nach sketch nur ein protokoll möglich ist und es in den meisten fällen falsch ist einfach das letztre definierte jeelink device zu verwenden so wie es bis her ist/war. was ich also machen werde in der parseFn der UNDEFINED meldung einen speziellen parameter IODEV=... mit zu geben der dann 1:1 an die defineFn durchgereicht wird. in der parseFn weiss ich welches IODev die nachricht die das autocreate triggert empfangen hat. eben eines das dieses protokoll versteht. dieser 'private' parameter der dann in define möglich ist wird aus DEF wieder entfern, landet also nie in der fhem.conf, wird aber beim AssignIoPort als proposed verwendet.
ohne proposed bleibt alles beim alten. sobald das device aber per autocreate angelegt wird genau ein mal das IODev gesetzt und im zweifel auch mit gespeichert. sobald aber der anwender es per attribut überschreibt hat auf jeden fall das den vorrang.
man muss nicht aufpassen da das autocreate vor jeder user interaktion kommt und somit alles was der user macht vorrang hat und einfach das proposed überschreibt.
der dreh und angelpunkt ist das jenige device das die erste nachricht von einem neuen device empfangen hat (die dann zum autocreate führt) bis zur definFn durchzuschleifen. wenn es also z.b. zwei cul im system gibt (ein mal slowRF und ein mal hm) wäre es immer der hm cul und niemals der slowRF cul weil dieser die nachricht garnicht empfangen haben kann. ganz unabhängig von der reihenfolge in der die beiden cul definiert sind.
das gleich ins attribut schreiben ist nötig weil es sonst das save nicht übersteht. und selbst wenn es im der fhem.cfg landen würde ist es kein problem weil die attribute nach der defineFn geladen und gesetzt werden. die user einstellung hat also selbst dann immer vorrang.
gruss
andre
Hallo Andre,
mal sehen, ob ich schon mit komme
a) dem eigentlichen Problem hier (user will ein netz mit 2 HM-IOs betreiben und die devices zuordnen) bringt es garnichts. Das muss der User von Hand machen.
b) AssignIoPort sucht nach einem kompatiblen device. Sollte das klappen (davon gehe ich aus) habe ich eine pseudo-zufalls Zuordnung. Wie ich "automatisch" besser werden kann verstehe ich nicht. Falls dass mit dem suchen nach kompatiblen devices bei jeelink nicht klappt hast du natürlich ein Problem.
c) das mit dem save verstehen ich nicht. IODev wird operational aus internal gespeist, nicht aus dem Attribut. Internals übersteht ein save. Es ist also nicht notwendig, das attibut wegen save zu setzen. Beim Hochfahren sollte der Mechaismus wieder greifen. Mehr noch - es wird der autoelle stand deiner Ermittlungen genommen. Wenn IODev erst einmal "automatisch" geschrieben wurde darf dein Mechanismus es auch nicht mehr beschreiben. Du blockierst dich also selbst.
Gruss Martin
hallo martin,
ein beispiel: es gibt zwei IODev, z.b. 2 x hmlan. egal ob mit unterschiedlicher id oder so weit auseinander das nur einer den aktor richtig empfängt. der anwender setzt hmPair und das neue device wird per autocreate angelegt.
ist zustand: fhem wählt das IODev 'zufällig' anhand der reihenfolge im config file ohne z.b. die hm id zu berücksichtigen.
mit proposed: du kannst genau das IODev das die nachricht die zum autocreate geführt hat von parse über autocreate und define bis zum AssignIoPort durchschleifen.
es wird also nicht 'automatisch' besser sondern dadurch das du fhem sagen kannst welches IODev die Nachricht empfangen hat. so das nicht mehr 'zufällig' ein kompatibles gewählt wird.
sobald es ein attribut IODev gibt wird damit der infernal value überschrieben. das attribut hat vorrang.
wenn es ein mal beim autocreate geschrieben wurde ist der automatismus vorbei und nicht mehr nötig.
gruss
andre
Hi Andre,
sollte in den meisten Fällen klappen. In den meisten Fällen gibt es aber sowieso nur ein HMLAN.
Ich müsste es allerdings mit Anlernen verknüpfen - das undefined ist etwas ungenau...
wenn einer 2 IO devices hat darf nicht das, genommen werden, welches sich zuerst meldet, sondern das, an dem pairen eingestellt ist. Die Laufzeit sollte nicht ausschlaggebend sein. Bei der Gelegenheit kann ich natürlich auch gleich das Attribut setzen - da ist eh jede Menge zu tun.
Es ist wohl ok das Attribut immer zu setzen, wenn gepairt wird - da habe ich dann auch das IO device und das anzulernende.
Immer automatisch bei undefined macht keinen sinn, da channels ja gar kein IODev haben ich muss eh auf devices filtern.
Warum es in AssignIoPort stattfinden sollte habe ich nicht verstanden. Ich spare ein attrVal das ich eh fix setzen kann, da ich alles schon habe.
Ausserdem werden ich berücksichtigen ,das attribut nicht zu setzen, wenn der user jegliche Automatik ausgeschaltet hat - da gibt es sonderwünsche....
habe ich noch etwas übersehen?
Gruss Martin
eigentlich sollte das mit dem besseren empfang genommen werden. aber das ist noch mal eine andere geschichte.
autocreate wird doch nur ausgelöst wenn du im anlern modus bist. da hast du ja dann das richtige IODev.
ja. das hatte ich gemeint. immer automatisch wenn angelernt wird. sonst natürlich nicht.
wenn man den normalen autocreate mechanismus verwendet ist es eigentlich völlig asynchron. die parseFn gibt UNDEFINED + parameter zurück und das autocreate modul ruft dann das define auf.
im parse kannst du das IODev attribut noch nicht setzen weil es das device noch nicht gibt, im define weisst du das richtige IODev nicht mehr wenn du es nicht übergibst. wenn du es übergibst kannst du natürlich das attribut auch selber setzen. meine version war mit allen prüfungen dann aber so lang das ich sie nicht in jedem modul haben wollte. deshalb die Idee es zentral zu machen. rudi hat es dann in AssignIoPort eingebaut (und so viel checks weg gelassen das es nur noch drei zeilen sind :) ).
gruss
andre
Zitateigentlich sollte das mit dem besseren empfang genommen werden. aber das ist noch mal eine andere geschichte.
hm - vielleicht. könnte sein, dass das Gerät nicht am finalen Standort angelernt wird - ich würde immer zum PC gehen beim Anlernen.
Das mit dem stärksten Empfänger kann man dynamisch machen - wenn einer mit der FB durch das Anwesen eilt. Ist aber problematisch, da man warten muss, ob noch von einem 2. Empfangen wird. Ausserdem darf man nicht üder den stärksten Empfänger senden, wenn die HMId nicht passt.
Zitatautocreate wird doch nur ausgelöst wenn du im anlern modus bist. da hast du ja dann das richtige IODev.
das entscheidende für HM ist nicht autocreate sonder pairen.
Channels werden autocreiert - dürfen aber nicht mit IODev belastet werden (können ja nicht senden).
Bei HM wird oft erst autocreiert und dann gepairt. Ich muss das IO device des pairens nutzen, nicht das des autocreate - ist sonst nicht korrekt.
Beim Pairen kann ich es dann schon. Und wenn nicht gepairt wird kann man eh nicht senden.
In CUL_HM muss ich sogar noch weniger checken, da es beim pairen passieren muss.
Ich greife also die Idee auf, aber den Mechanismus leider nicht. autocreate hat nicht die notwendige Info. Schlimmstenfalls wird dann ein IOdevice mit falscher HMId genutzt. kann für andere anders sein, bei HM nicht genau genug - darf man nicht an dieser Stelle machen.
Danke für die Idee.
Martin
Zitat von: martinp876 am 17 Dezember 2013, 16:04:21
Das mit dem stärksten Empfänger kann man dynamisch machen
vielleicht wäre es in einem ersten schritt eine möglichkeit in hminfo nicht nur die nakten rssi werte einzubauen sondern eine art 'vorschlag' der direkt im klartext anzeigt wenn ein anderes iodev besser wäre. vielleicht sogar mit konsitenzprüfung hinsichtlich der hmid.
Zitat von: martinp876 am 17 Dezember 2013, 16:04:21
Ausserdem darf man nicht üder den stärksten Empfänger senden, wenn die HMId nicht passt.
das ist klar.
Zitat von: martinp876 am 17 Dezember 2013, 16:04:21
Bei HM wird oft erst autocreiert und dann gepairt. Ich muss das IO device des pairens nutzen, nicht das des autocreate - ist sonst nicht korrekt.
wenn du autocreate nur für die channel und nicht für die devices an sich verwendest ist der mechanismus natürlich nicht passend. bei meinen devices passt es immer. aber die idee fhem bei der wahl des richtigen IODev zu unterstützen bleibt ja richtig.
gruss
andre
Hi Andre,
das Problem mit RSSI ist, dass die Messages der Reihe nach rein kommen, mit delay von bis zu einigen 10 ms. Wenn ich es also auswerten will muss ich warten - und das timing dennoch einhalten . Komplex - erzeugt in jeden Fall CPU last - timer für jede mesage...
Ich gehe davon aus, dass es erst ein wirklicher Vorteil ist, wenn es dynamisch funktioniert - statisch kann der User auch. Rudi hat schon so etwas wie IOGroups eingebaut - darauf müsste man aufsetze. Der eigentliche Vorteil besteht nicht bei statischen devices sondern FBs die durchs Haus wandern. Wobei nur wenigen FBs etwas empfangen wollen (RC19 ...).
Autocreate wird für devices und channels genutzt. Autocreate und pair sind aber unterschiedlich. Um ein IO device festzulegen ist pairen der Zeitpunkt, nicht autocreate. Dann hat der User ein Device erwählt, über das er pairen will - das sollte dann auch IODevice werden. Alles andere macht im Hinblick auf eine Automatik keinen Sinn - zumindest bei HM.
Gruss Martin
Hallo Leute,
wollte nur kurz mitteilen, dass jetzt alles wieder läuft - habe die IODev "händisch" auf den HMLAN1 zurückgestellt. Die Glühbirne im Wintergarten geht ebenfalls wieder - nachdem ich die LED durch eine gute alte Glühbirne ersetzt habe - nicht energiesparend - aber funktioniert (was mich nur nach wie vor wundert, ist, dass es vor dem zuschalten des zweiten HMLAN funktioniert hat???)
Was ich eine gute Idee finde, ist, dass sich ein Gerät immer die IODev bzgl HMLAN einträgt, an das es gepaired wurde - ich hatte anfangs die Vermutung, dass dies genauso wäre - speziell da ich ja bereits vorhandenen Geräte hatte die an den HMLAN1 gepaired waren. Ich habe mir zunächst gar nicht vorstellen können, dass die sich irgendwie am zweiten HMLAN anmelden könnten - dachte immer so ein pairing wäre sowas wie der "Bund fürs Leben" bzw. bis das Gerät manuell wieder in den Pairing Modus versetzt wird und dann an einen anderen HMALN gebunden wird ...
so, nachdem dieses Problem jetzt gelöst ist, habe ich natürlich direkt das nächste ;D
1. Auf meiner Fritzbox läuft das fhem Image von AVM und ich will das von fhem.de nutzen. Kann ich das von fhem direkt drüberbügeln - wahrscheinlich nicht, da dann meine fhem.cfg und meine 99_MyUtils weg ist ...
Gibt es da ein TUT für den Umstieg?
2. Um meine Daten nicht zu verlieren, wollte ich ein <backup> machen - funktioniert leider nicht - bekomme was von broken pipe gemeldet
3. Dachte mir - vielleicht ist der interne Speicher der fritzbox voll - leg ich halt das backup auf die angeschlossene externe 2 TB HD - dazu habe ich folgendes in die fhem.cfg eingetragen
attr global backupdir /var/InternerSpeicher/WD-ExtHDD1021-01/fhem_backup
will irgendwie nicht. Wie komme ich überhaupt auf die externe HD? das Verzeichnis /var/ in der fhem.cfg verweist ja bereits auf das Unterverzeichnis von fhem - und nicht auf das Verzeichnis /var/ im root der FB (i.e. ist eigentlich /var/InternerSpeicher/fhem/var
Hatte eben schon den ersten Herzkasper als ich die Funktion Backup in meine fhem.cfg eingefügt hatte und dann diese durcheinander war - ich wollte dann meine -glücklicherweise vorher von der FB mittels NAS Zugriff gesicherte - fhem.cfg rücksichern - und bekam dann die Meldung ich solle mehr Speicher freigeben .... (und das bei einer Datei von gerademal 12 KB!)
So viele Fragen ....
Hallo,
bitte den Beitrag nicht "kapern" sondern eine neue Frage im richtigen Bereich aufmachen.
Für FB findest du u.a. jede Menge Treffer und "TUT" im Forum wie du das AVM-Image wieder los wirst und das fhem.de drauf bekommst.
evtl. wäre diese Info auch vorher schon interessant gewesen.
Grüße
Nachtrag zum IO device - das automatische setzen sollte jetzt drin sein - beim pairen
Hallo puschel74,
<evtl. wäre diese Info auch vorher schon interessant gewesen>
wieso vorher - vor was?
Sascha
p.s.: meinen eigenen Thread kann ich schlecht "kapern" :) - aber hast schon recht - sollte dafür einen neuen Thread aufmachen - war halt in dem Moment so im "flow" mit schreiben - sorry - kopiere den Inhalt gleich in einen neuen Beitrag rein
Hallo,
Zitatwieso vorher - vor was?
Vor der eigentlich ersten Frage.
Es macht durchaus einen Unterschied (hier jetzt vielleicht nicht) ob du das AVM-Image verwendest oder das von fhem.de
Zitatp.s.: meinen eigenen Thread kann ich schlecht "kapern"
es ist ja auch nicht "dein eigener" Beitrag sondern ein Beitrag wo es um 2 HM-LAN geht.
Das hat weder mit der FB noch mit den anderen Fragen etwas zu tun.
Zitatkopiere den Inhalt gleich in einen neuen Beitrag rein
Versuch doch erstmal die Suchfunktion ;)
Die ist garnichtmal so schlecht und spuckt mit den richtigen Begriffen auch passende Beiträge aus ;D
Den jede der "neuen" Fragen wurden bereits im Forum beantwortet.
Grüße