Neues Modul: 22_HOMEMODE.pm - grundlegende Automationen und mehr

[DeeSPe]

Hallo dan,

meine PCA301 Messdosen liefern power und consuption (statt energy) readings. Wäre es möglich das noch konfigurierbar zu machen?

Grüße

Hatte anfangs überlegt das konfigurierbar zu machen, dachte aber dass power und energy einigermaßen konsistent wären.
Ohne dass ich das Modul diesbezüglich überarbeiten müsste, könntest Du Dir mit einem ganz einfachen userReading in den Devices selbst behelfen:

Code: [Auswählen]

attr <device> userReadings energy:consuption.* {ReadingsNum($name,"consuption",0)}
Gruß
Dan

[fhainz]

Danke, klar mir einem userReading geht es jetzt schon.

Vielleicht schafft es die konfiguration ja in eine zukünftige Version

Grüße

[Chris8888]

In der Doku ist das als Devspec deklariert und somit eindeutig beschrieben. (siehe commandref)

Was für Bewegungsmelder hast Du?
Evtl. werden die falschen Readings/Vals benutzt?
Schau Dir die Attribute HomeSensorsMotionOpenTamperReadings und HomeSensorsMotionOpenTamperVal an.

Gruß
Dan

Hi, wer lesen kann...das Problem lag zwischen den Ohren.
Nachdem ich die Readings
HomeSensorsMotionOpenTamperReadings state cover
HomeSensorsMotionOpenTamperVal motion|open
gesetzt habe funktioniert es auch.

Danke für den Schubs in die richtige Richtung!

VG
Christian

[DeeSPe]

Danke, klar mir einem userReading geht es jetzt schon.

Vielleicht schafft es die konfiguration ja in eine zukünftige Version

Grüße

Hab's mal unten auf die Todo-Liste gesetzt.
Sehe hier allerdings die selbe Problematik wie bei den Kontakt- und Bewegungssensoren. Bei gemischter Umgebung wäre das in einem globalen Attribut wieder nicht abzudecken und müsste somit als Attribut in jeden Energiesensor geschrieben werden. Klar, ist machbar, aber evtl. ist ein userReading dann doch einfacher!?

Hi, wer lesen kann...das Problem lag zwischen den Ohren.
Nachdem ich die Readings
HomeSensorsMotionOpenTamperReadings state cover
HomeSensorsMotionOpenTamperVal motion|open
gesetzt habe funktioniert es auch.

Danke für den Schubs in die richtige Richtung!

VG
Christian

Schön dass Du es damit hinbekommen hast.
Genau deshalb ist das konfigurierbar!

Gruß
Dan

[fhainz]

Sehe hier allerdings die selbe Problematik wie bei den Kontakt- und Bewegungssensoren. Bei gemischter Umgebung wäre das in einem globalen Attribut wieder nicht abzudecken und müsste somit als Attribut in jeden Energiesensor geschrieben werden. Klar, ist machbar, aber evtl. ist ein userReading dann doch einfacher!?

Da hast du recht. An das hab ich gar nicht gedacht.

[DeeSPe]

Da hast du recht. An das hab ich gar nicht gedacht.

Ich habe bei der Entwicklung dieses Moduls alle mir erdenklichen Szenarien durchgespielt.
Das wird sicher bei Weitem noch nicht alle Anwendungszwecke abdecken, aber zumindest die meisten...
Und genau über diesen Fall bin ich auch gestolpert, dachte aber sofort an userReadings und somit war das DIE Lösung für mich.
Der einzige Fall der damit nicht abgedeckt ist wäre, wenn ein Device z.B. power für on/off benutzt und ein anderes Reading für die power Werte.

Gruß
Dan

[binford6000]

Hi Dan,
cooles Modul hast Du da gebaut! Ich konnte schon einiges entsorgen...

Was HomeSensorsPowerEnergy angeht würde sich der Eine oder Andere wünschen, dass auch devices wie PRESENCE
oder DUMMY mit "power on" und "power off" Attribut ausgewertet werden.

Und beim Kalender-Teil eine Auswertung von Ferien und Feiertagen auch direkt über CALENDAR-devices.
Ich meine aber gelesen zu haben, dass Du das evtl. schon auf dem Schirm hast...

VG Sebastian

[DeeSPe]

Hi Dan,
cooles Modul hast Du da gebaut! Ich konnte schon einiges entsorgen...

Freut mich! 

Was HomeSensorsPowerEnergy angeht würde sich der Eine oder Andere wünschen, dass auch devices wie PRESENCE
oder DUMMY mit "power on" und "power off" Attribut ausgewertet werden.

Das ist aber zum Erfassen der Energiewerte gedacht und nicht zum Erfassen ob on/off.
Durch Angabe des richtigen Devspec bist Du nur dadurch eingeschränkt dass die Devices eben jeweils ein energy und power Reading besitzen müssen.

Und beim Kalender-Teil eine Auswertung von Ferien und Feiertagen auch direkt über CALENDAR-devices.
Ich meine aber gelesen zu haben, dass Du das evtl. schon auf dem Schirm hast...

Steht auf der Todo-Liste, hab aber noch keinen Plan wie ich das umsetzen kann.
Muss mich dazu erst einmal näher mit den entsprechenden Kalender Modulen befassen.
Ich muss halt irgendwie alle Events mit einem Mal auslesen können um entsprechende HomeCMD Attribute zu kreieren. Das geht bisher bei den holiday Kalendern am einfachsten.

Gruß
Dan

[EnderPhilipp]

Habe ein kleines "Problemchen":
Und zwar habe ich mein iPhone per Presence in FHEM eingebunden, wenn jetzt aber der Akku leergeht, ist das iPhone natürlich "absent" und mein Resident auch...

Meine Frage ist, kann ich sagen, dass HomeAutoPresence meinen Status nur auf home setzten kann, aber nicht auf absent ?

Finde das Modul aber sehr praktisch, viele dummies und notifies sind dafür gestorben. 

Mfg 
Philipp

[DeeSPe]

Habe ein kleines "Problemchen":
Und zwar habe ich mein iPhone per Presence in FHEM eingebunden, wenn jetzt aber der Akku leergeht, ist das iPhone natürlich "absent" und mein Resident auch...

Meine Frage ist, kann ich sagen, dass HomeAutoPresence meinen Status nur auf home setzten kann, aber nicht auf absent ?

Nein! Denn das widerspricht m.E. der Logik von Presence Devices.
Evtl. helfen Dir ein oder mehr weitere Presence Devices weiter (z.B. AVR).

Gruß
Dan

[binford6000]

Das ist aber zum Erfassen der Energiewerte gedacht und nicht zum Erfassen ob on/off.
Durch Angabe des richtigen Devspec bist Du nur dadurch eingeschränkt dass die Devices eben jeweils ein energy und power Reading besitzen müssen.

Ja genau! Beispiel: Energiesparlampe 10 Watt

Code: [Auswählen]


 Internals:
   CFGFN
   NAME       Lampe1
   NR         12796
   STATE      on
   TYPE       dummy
   Readings:
     2017-01-08 15:37:20   state           on
Attributes:
   power-off  0.5
   power-on   10
Elektrolurch hat das mal als EMONITOR gebaut, siehe hier: https://forum.fhem.de/index.php/topic,30055.0.html

Die Attribute können in jedes Device eingebaut werden, welche keine eigenen energy und power Readings besitzen.
Hab es bei mir noch in HUEDevice, ENIGMA2, YAMAHA_AVR, XBMC (on/off) und diversen dummys (Dauerverbraucher wie Kühlschrank usw.) eingebaut.

VG Sebastian

[DeeSPe]

Elektrolurch hat das mal als EMONITOR gebaut, siehe hier: https://forum.fhem.de/index.php/topic,30055.0.html

Als Entwickler kann man nicht auf Alles Rücksicht nehmen.

Wie schon beschrieben löst ein einfaches userReading das Problem.

Hatte anfangs überlegt das konfigurierbar zu machen, dachte aber dass power und energy einigermaßen konsistent wären.
Ohne dass ich das Modul diesbezüglich überarbeiten müsste, könntest Du Dir mit einem ganz einfachen userReading in den Devices selbst behelfen:

Code: [Auswählen]

attr <device> userReadings energy:consuption.* {ReadingsNum($name,"consuption",0)}
Gruß
Dan

Gruß
Dan

[Spezialtrick]

Das Modul ist einfach genial. Notify's und DOIF's fliegen eines nach dem anderen raus. 

@Dan:

Hast du eine Idee wie man eine HM-Sec-Sir-WM Sirene und eine HM-RC-Sec4-2 integrieren könnte, sodass diese sowohl über das Modul als auch autark mit entsprechenden HM-Fensterkontakten funktionieren?

[DeeSPe]

Das Modul ist einfach genial. Notify's und DOIF's fliegen eines nach dem anderen raus. 

So ist es gedacht! 

@Dan:

Hast du eine Idee wie man eine HM-Sec-Sir-WM Sirene und eine HM-RC-Sec4-2 integrieren könnte, sodass diese sowohl über das Modul als auch autark mit entsprechenden HM-Fensterkontakten funktionieren?

Ich kenne die Geräte nicht! Aber bei HM gehe ich mal davon aus dass Du die peeren musst. Wie das Auslösen, also wann weiß die Sirene dass sie in einem Alarmmodus ist in dem sie auslösen soll, da realisiert wird weiß ich nicht.
Im HOMEMODE Device könntest Du sie dann einfach im Attribut HomeCMDalarmTriggered-on angeben dass sie Lärm machen soll.

Gruß
Dan

[binford6000]

Das Modul ist einfach genial. Notify's und DOIF's fliegen eines nach dem anderen raus.

Genauso sieht's bei mir aus! Ein Reading für Wochenende bzw. Arbeitswoche wäre noch ganz praktisch...