Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
Hallo zusammen,

hat zufällig jemand noch eine aktuelle Platine?

Viele Grüße
Gehrt
2
Mir ist dazu noch eine Idee gekommen. Das sind ja Default-Werte für ein spezifisches Modul (in dem Fall SVG). Wäre es nicht generell sinnvoll, dass man irgendwie global Defaults definieren kann für Devices bestimmter Typen?

D.h. nicht "FHEMWEB" hat ein Attribut "endPlotNow", was der Default von Device-Type "SVG" darstellt, sondern "global" hat ein Attribut "deviceDefaults", und da trägt man als String ein z.B. "SVG:endPlotNow=1,blabla=2,... AndererTyp:a=x,b=y"
Das wäre dann generisch, und müsste auch nicht erweitert werden, wenn Devices neue Attribute bekommen.

Hab dazu nichts auf die Schnelle gefunden. Oder gibt es das schon?
3
Hallo zusammen,

ich habe  mir auch was zusammen gebaut, um den Wasserzähler abzulesen. Ich habe jedoch 2 Probleme, für die ich keine Lösung finde.

1. Das MQTT-Device wurde direkt in FHEM erkannt und angelegt, es gibt jedoch keine Readings (d.h. keine Zählerstände). Es taucht nur alle paar Minuten im Reading connection "connection lost" auf. Muss ich in attrTemplate einen Wert setzen?
2. Der ESP32CAM rebootet alle paar Minuten scheinbar. Ich bin mir aber nicht sicher. Ich mache das fest an der Nichterreichbarkeit des Web-Interfaces.

Wie läuft der ESP bei euch soweit? Fehlerfrei?
Hat jemand Tipps? Ich habe noch den PIN von GPIO0 entfernt und auf der Oberseite mit ALU-Band abgeklebt. Das habe ich als Hinweis im Netz gefunden. Resultat war eine wesentlich bessere WLAN-Verbindung - Bilder erschienen sofort, im Gegensatz zu vorher teilweise gar nicht und wenn, mit extremen Wartezeiten, also unbenutzbar.

Viele Grüße
Gehrt
4
Anfängerfragen / Antw:DOIF funktioniert nicht mehr - Liegt es am Update?
« Letzter Beitrag von Ruggy am Heute um 08:22:05 »
Vor dem Reset-Test hätte man noch fhem stoppen können, also deCONZ weiterlaufen lassen und schalten...
Nicht, dass doch eine "unbekannte" /"vergessene" Logik in fhem die Ursache ist...
Gruß, Joachim

Stimmt, das wäre noch eine gute Möglichkeit gewesen um bei dem Problem wieder etwas auszuschließen.

Kann es eine verstecke Logik geben?
Das automatische ausschalten war auch gegeben, als ich eine andere Steckdose (mit anderen Gerätenamen HUEDevice9 und HUEDevice11) verwendet hatte.
5
Anfängerfragen / Antw:DOIF funktioniert nicht mehr - Liegt es am Update?
« Letzter Beitrag von MadMax-FHEM am Heute um 08:16:16 »
Vor dem Reset-Test hätte man noch fhem stoppen können, also deCONZ weiterlaufen lassen und schalten...

Nicht, dass doch eine "unbekannte" /"vergessene" Logik in fhem die Ursache ist...

Gruß, Joachim
6
Homematic / Antw:HMCCURPCPROC Fehlermeldungen
« Letzter Beitrag von kjmEjfu am Heute um 08:15:01 »
Wenn es aber doch zu Fehlermeldungen in RaspberryMatic führt, dann könnte doch sehr wahrscheinlich ein entsprechender Hinweis auf https://homematic-forum.de/forum/ dazu führen, dass Jens es fixt?
7
Anfängerfragen / Antw:DOIF funktioniert nicht mehr - Liegt es am Update?
« Letzter Beitrag von Ruggy am Heute um 08:12:46 »
Die Lüfter benötigen nicht viel Strom. Es sind zwei Lüfter, welche gleichzeitig einschalten. Insgesamt brauchen sie 50 Watt.

Habe jetzt anstatt der Osram Smart+ Plug Steckdose eine Shelly Plug1 verwendet. Dies funktioniert bisher.
Die Lüfterklappten vom Rohr bleiben vorerst immer geöffnet. Das Xiaomi Schaltrelais dafür ist abgeklemmt.

Dies ist ein Notbehelf, damit der Keller zumindest wieder belüftet wird.


Hab vor, einen Conbee II Stick bestellen. Evlt. liegt es ja an diesen?
Oder gibt es einen "besseren" für Zigbee?

Welcher Schaltaktor wäre zuverlässiger als der Xiaomi (benötige 2 Relais)?
Der Homematic 2fach Unterputz Schaltaktor?

Oder gäbe es eine zuverlässigere Methode (nur für die Schaltung für die Lüftung)?


Die Steckdose schaltet sich sogar automatisch aus, auch wenn ich sie manuell am Taster einschalte.
Habe mich mal selber Zitiert.
Wie es aussieht ist dies aber nur, wenn sie mit den Conbee verbunden sind. Habe die Steckdose länger vom Strom gehabt und mehrmals einen Reset durchgeführt. Danach hat sie sich bisher nicht mehr selber ausgeschaltet.

Den Thread-Titel ändere ich. Fällt nur auf die schnelle nicht ein, was aussagekräftig für das Problem ist.
8
Automatisierung / Antw:[HOMEMODE] Türsteuerung abends
« Letzter Beitrag von caldir65 am Heute um 08:12:25 »
Moin,

ich habe es jetzt komplett aus Homemode heraus genommen - über doif ist es m.M. nach einfacher und vor allem auch flexibler umzusetzen...

Gruß, Christoph
9
Moin,

ich muss das mal wieder hochholen, da es nicht mehr funktioniert. Warum auch immer - ich bin am verzweifeln :(
Die Definition des notify sieht so aus:

Urlaubstage:changed:.*start|Urlaubstage:changed:.*end {
   my $stat=($EVTPART2 eq "start")?1:0;
   fhem("set Urlaubstag $stat") if defined fhem('get '.$NAME.' events filter:uid=="'.
#         $EVTPART1.'",field(summary)=~"(?i)Urlaub" limit:count=1,from=0',1)
         $EVTPART1.'",field(summary)=~"(?i)Urlaub" limit:count=1',1)
}

Es wird allerdings nur das start event getriggert, niemals das "end" event. Die triggeredByEvent Zeit steht - obwohl das Event schon lange vorbei ist immer noch auf "changed: ID_DES_EVENTS end" Spannend ist - dass wenn ich das "end" von Hand triggere mit:

trigger Urlaubstage changed: ID_DES_EVENTS end

wird der Urlaubstag auf 0 gesetzt.

Kann mir hier nochmal jemand helfen bitte? Ich habe mal wieder keine Ahnung wo ich ansetzen soll. Zu allem Überfluss sagt mir das Log auch noch:

get Urlaubstage end is deprecated and will be removed soon. Use get Urlaubstage events instead.
Das heisst ich muss das sowieso bald wieder anfannse? *seufz*
10
TabletUI / Antw:[FUIP] Calendar-View - Ansichten
« Letzter Beitrag von caldir65 am Heute um 08:09:14 »
Moin Thorsten,

ist nicht schlimm - ich habe eh im Moment nicht so viel Zeit zum Ausprobieren  ;)

Gruß, CHristoph
Seiten: [1] 2 3 ... 10