Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
Sonstiges / Antw:FHEM nur mit kompatiblen WLAN Geräten betreiben
« Letzter Beitrag von frank am Heute um 14:36:13 »
Zitat
Irrglaube: wenn ein Gerät per WLAN angebunden ist, dann kann es automatisch integriert werden. Falsch, weil es ja nicht heißt, dass die empfangenen (über den Übertragungsweg WLAN) Daten auch "verstanden" werden (Protokoll)...
das wär ja die absolute katastrophe, wenn jedes wlan gerät, dass bei mir vorbei geht oder fährt, automatisch ein device erzeugen würde.
2
Homematic / Antw:[CUL_HM] patches Oktober 2021 - die Zweite
« Letzter Beitrag von frank am Heute um 14:27:59 »
ok, mit den fehlermeldungen ist klar, dass die einschränkung bei folgender zeile (1728ff) erfolgen muss:

  if(!$mh{devH} && $mh{mTp} eq "00") { # generate device
    my $sname = "HM_$mh{src}";
    my $defret = CommandDefine(undef,"$sname CUL_HM $mh{src}");
    Log 1,"CUL_HM Unknown device $sname is now defined ".(defined $defret ? " return: $defret" : "");
3
Homematic / Antw:CMDs_pending bei der Aktualisierung der Temperaturliste
« Letzter Beitrag von MadMax-FHEM am Heute um 14:27:46 »
Das habe ich mit Absicht noch nicht gemacht. Ich glaube dann funktionieren bei mir manche Schalter nicht mehr korrekt.
Das wollte ich mir in Ruhe mal anschauen. Und wenn dann wollte ich im Attribut "event-on-change-reading" auch direkt die relevanten Readings setzen.

Man kann auch per event-on-update-reading die (hoffentlich) paar relevanten Readings wieder "reinnehmen"...
...weil ansonsten wird evtl. die Liste mit event-on-change zu unübersichtlich...

Aber da muss man dann pro Device schauen was übersichtlicher ist...
Ich mache das meist "global" mittels event-on-change-reading .* und hole mir dann "zurück" (event-on-update) was ich für Loggen oder Automatisierungen (notify etc.) brauche...

Bei DOIF-Tools gibt's die Möglichkeit sich eine "Event-Statistik" generieren zu lassen, ist ganz interessant zu sehen was da so im System an Events unterwegs ist und welche Devices besonders "geschwätzig" sind...
Dort kann/sollte man dann als erstes ansetzen...

Gruß, Joachim
4
Zitat
Aber wir bekomme ich den Weg hin, aus FHEM dann das am ESP8266 angeschlossene Relais zu schalten?
Oder habe ich einen Gedankenfehler?

Im Falle MQTT2 und Tasmota (geht mit ESPEasy denk ich doch auch) auf dem ESP, konfigurierst du einfach den verwendeten GPIO auf POWER1, aktivierst MQTT in den Einstellungen, schaltest das Relais oder Neustart des ESP einmal und daraufhin wird automatisch ein MQTT2_DEVICE in FHEM erstellt.
Auf dieses Device wendet man einfach das tasmota_basic-Template (set <devicename> attrTemplate tasmota_basic) an und kann ab dann das Relais aus FHEM steuern.
5
Sonstiges / Antw:FHEM nur mit kompatiblen WLAN Geräten betreiben
« Letzter Beitrag von MadMax-FHEM am Heute um 14:21:34 »
Zitat
Trotzdem würde ich nun gerne diesen "Single Point of Failure" aus meinem System bekommen...

Und wie ist/soll damit der single point of failure weg sein?
Damit hast du doch nur einen anderen?

Und wenn nun alle Sensoren/Aktoren nur noch über WLAN laufen, dann hast du doch danach EINEN single point of failure für ALLE Geräte.

Zuvor ja nur "partiell", also:

Zigbee fällt aus -> Zigbee Geräte "weg"
ZWave fällt aus -> ZWave Geräte "weg"
usw.

Zitat
... frage mich, ob es für die üblichen Sensoren/Aktoren mittlerweile Alternativen ohne eigenes Protokoll gibt.

Alle haben ein Protokoll!
WLAN ist ja nur der Übertragungsweg!

Irrglaube: wenn ein Gerät per WLAN angebunden ist, dann kann es automatisch integriert werden. Falsch, weil es ja nicht heißt, dass die empfangenen (über den Übertragungsweg WLAN) Daten auch "verstanden" werden (Protokoll)...

Und es gibt ja von Shelly: H/T, BWM, mittels uni -> alles mögliche usw.

Aber da wäre ich auch vorsichtig, weil zu viele WLAN-Geräte ja auch irgendwann problematisch werden können...

Und wie (eingangs geschrieben) wenn WLAN "ausfällt", dann ist ja gleich "alles weg"...

Viel Erfolg, Joachim
6
Homematic / Antw:CMDs_pending bei der Aktualisierung der Temperaturliste
« Letzter Beitrag von frank am Heute um 14:18:52 »
Zitat
Das habe ich mit Absicht noch nicht gemacht. Ich glaube dann funktionieren bei mir manche Schalter nicht mehr korrekt.
Das wollte ich mir in Ruhe mal anschauen. Und wenn dann wollte ich im Attribut "event-on-change-reading" auch direkt die relevanten Readings setzen.
wenn man wirklich ein, zwei readings mit events bei jedem update braucht, muss man einfach nur zusätzlich event-on-update für diese ein, zwei readings setzen. aber auch für schalter sollte es nicht nötig sein, wenn notify/doif sinnvoll definiert sind.
event-on-change noch mehr einschränken, kann man dann immer noch.
hauptsache nicht zu lange warten.


übrigens:

Auf jeden Fall scheint
attr TYPE=CUL_HM:FILTER=subType!=virtual:FILTER=model!=VIRTUAL:FILTER=device=:FILTER=NAME!=ActionDetector commStInCh offgeholfen zu haben.

warum hast du alle virtuellen devices rausgefiltert?
es ist in allen devices (6-stellige DEF) sinnvoll, ausser dem actiondetector.
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000 commStInCh off
aber dem actiondetector tut es scheinbar auch nicht weh, denn ich hatte bei mir einfach den letzten vorschlag von martin ausgeführt:
attr TYPE=CUL_HM:FILTER=DEF=...... commStInCh off
7
you install fhem directly in the fritzbox (1)    --> don't like to modify the FritzBox
or use ser2net on the  fritzbox   (2)              --> found no description of this config and the need of a RS232 HW still remain
or use  fhem on a raspberry  (3)                  --> did You try to buy a raspi today?
or use  ser2net on a raspberry (4)                -->
or use  fhem on a nas (5)                            --> not availabel and not planned

In my understanding ser2net needs in any case an additional host for com port. I'm wrong?
Fritz USB remote do not need an additional host.

I use vnc to connect to the FHEM host = netbook.
Because power consumption of this netbook I would like to remove it.
One year ago I bought a rasberry 4 kit as a gift for a person.
Today same part nearly double price and not deliverabel.

Matthias
8
Anfängerfragen / Antw:FHEM Plot aus anderen Datenquellen
« Letzter Beitrag von xenos1984 am Heute um 14:14:33 »
Du kannst mit logproxy auch eine Perl-Funktion zur Generierung der Daten benutzen, und die kann ihre Daten von überall holen. (Ich nutze die z.B. um Daten einer Wettervorhersage aus verschiedenen Quellen einzubinden.)
9
Anfängerfragen / Notify löst seit 2 Tagen nicht mehr aus
« Letzter Beitrag von Helmi55 am Heute um 14:14:09 »
Hallo
mein System und ich stehen seit einigen Tagen auf Kriegsfuß  :)
Habe auf meinem Produktionssystem ein notify das mir den Pelletsstand von meinem Ofen holt und in einen dummy schreibt.
Am Testsystem funktioniert es allerdings?
Die readings vom Ofen sind identisch.
Hier ein List von der Produktion
Internals:
   DEF        Ofen:sensors_parameterFeedRateTotal.* set du_PelletsOfen $EVTPART1
   FUUID      6172a7bc-f33f-ee2d-a969-3cc52a56d7d82d58
   NAME       ny_Uebertrag
   NOTIFYDEV  Ofen
   NR         621
   NTFY_ORDER 50-ny_Uebertrag
   REGEXP     Ofen:sensors_parameterFeedRateTotal.*
   STATE      active
   TYPE       notify
   READINGS:
     2021-10-22 14:06:31   state           active
Attributes:
   alias      ny_Uebertrag
   room       Steuerung

wenn ich im eventMonitor kontrolliere (set nyÜebertrag active) bekomme ich diese Meldung  = 2021-10-22 14:06:31 notify ny_Uebertrag active

Der Wert stimmt aber nicht mit dem Sensor des Ofens überein.

Hier das List vom Testsystem

Internals:
   DEF        Ofen:sensors_parameterFeedRateTotal.* set du_PelletsOfen $EVTPART1
   FUUID      5c45c885-f33f-ee2d-b80d-019e10b654fad542
   NAME       ny_Uebertrag
   NOTIFYDEV  Ofen
   NR         285
   NTFY_ORDER 50-ny_Uebertrag
   REGEXP     Ofen:sensors_parameterFeedRateTotal.*
   STATE      2021-10-22 14:12:04
   TRIGGERTIME 1634904724.61765
   TYPE       notify
   READINGS:
     2021-10-22 13:21:46   state           active
Attributes:
   alias      ny_Uebertrag
   room       Steuerung

Ich sehe als Unterschied nur die Triggertime und bei state einmal active und einmal mit Uhrzeit

Wo kann ich da bitte ansetzen?
Es wurde nix am System in letzter Zeit verändert

Danke und LG
Helmut
10
FHEMWEB / Antw:Modul weekprofile + FHEMWEB widget
« Letzter Beitrag von stolus am Heute um 14:09:57 »
@Risiko
Ich nutze das Modul "weekprofile" schon länger, vielen Dank für Deine Arbeit!

Im Moment habe ich gerade den Überblick verloren welche Arten von Devices unterstützt werden.
Ich bin auf das Modul "HMCCU" (Raspberymatic) umgestiegen und nutze die Version 5.0 von HMCCU.

Die meisten Devices in FHEM (z.B. HM-CC-RT-DN) werden jetzt in Version 5.0 als TYPE=HMCCUCHN angelegt, beim Übertragen des profils (send to device) kommt die Fehlermeldung "Error device type not supported"

Ich habe mehrere Thermostate zu Heizgruppen in der CCU (Raspberymatic) zusammengefügt, daraus wird in FHEM ein Device mit dem TYPE=HMCCUDEV, allerdings ein VirtualDevices ccutype=HM-CC-VG-1.
Beim Übertragen des profils (send to device) kommt die Fehlermeldung: "KEL.Wohnen.Heizgruppe Invalid parameter specified. Valid parameters are HASH(0x55fe5e9b1328)"

Hier komme ich leider alleine nicht weiter und benötige eine Rat.

Seiten: [1] 2 3 ... 10