Neueste Beiträge

#1

Sonstiges / Aw: Homebridge läuft, oder auc...

Letzter Beitrag von maxritti - 18 April 2024, 07:33:17

Welches OS genau, also Version?
Da neu aufgesetzt hoffentlich neue(ste) Version...

Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

Seit langem startet Linux mittels systemd, du startest homebridge (immer noch) über initd...

Wenn es nach einiger Zeit und manuellem (Re)Start läuft, tippe ich drauf, dass eben irgendwas beim Start nach Boot noch nicht verfügbar ist...

-> Start verzögern?

Es gibt auch ein Modul in fhem zum Steuern von Diensten, evtl. bei global:INITIALIZED den Service aus fhem starten...

Gruß, Joachim

Danke für die Hinweise, werde ich mich mal schlau machen.

Ggf. könnte der Wiki Eintrag dahingehend erweitert werden!?
Keine Ahnung

#2

Sonstiges / Aw: Homebridge läuft, oder auc...

Letzter Beitrag von MadMax-FHEM - 18 April 2024, 07:13:21

Welches OS genau, also Version?
Da neu aufgesetzt hoffentlich neue(ste) Version...

Seit langem startet Linux mittels systemd, du startest homebridge (immer noch) über initd...

Wenn es nach einiger Zeit und manuellem (Re)Start läuft, tippe ich drauf, dass eben irgendwas beim Start nach Boot noch nicht verfügbar ist...

-> Start verzögern?

Es gibt auch ein Modul in fhem zum Steuern von Diensten, evtl. bei global:INITIALIZED den Service aus fhem starten...

Gruß, Joachim

#3

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von TheTrumpeter - 18 April 2024, 06:54:28

Edit: Also mit den Shellys geht das auch Problemlos. Diese sind über MQTT angebunden. Keine Ahnung ob dadurch Unterschiede gibt.
Fakt ist das Tasmota und Shellys über MQTT ausschalten bei on-for-timer. Auch bei nicht mehr laufender Automation.

Der Auszug von oben ist aus der CommandRef zu den "set extensions". Da steht auch dabei, dass im Zweifelsfall die Modul-eigene Implementierung "gewinnt". Offensichtlich unterstützen die Shellys und Tasmota eine Art "Timer/Countdown" am Gerät selbst, d.h. beim Absetzen von "on-for-timer" wird dem Gerät direkt mitgegeben wie lange das Gerät eingeschaltet sein soll. (Ähnlich wie der "countdown" bei Tuya, aber möglicherweise sogar in einem einzigen Befehl?)
MQTT hat damit nix zu tun, das müsste egal sein wie Du mit den Dingern kommunizierst.
Meine Bewässerung wird von einem ESP32 mit ESPEasy angesteuert, da setze ich in FHEM auch die Befehle ab, die die Timer direkt am Gerät laufen lassen. (Zusätzlich habe ich dort noch eine interne und zwei externe Überwachungen eingebaut, die dafür sorgen, dass die Ventile bei einem Gerätereboot oder allerspätestens bei Sonnenaufgang geschlossen werden. Wird paar Minuten nach Sonnenaufgang immer noch Wasser verbraucht, dann wird die gesamte Steuerung über eine schaltbare Steckdose vom Netz genommen. Spätestens dann muss Ruhe sein.)

[ps -aux | grep -I homebridge]

#4

Sonstiges / Homebridge läuft, oder auch ni...

Letzter Beitrag von maxritti - 18 April 2024, 06:50:01

Hallo zusammen,

Ich bin ja schon länger bei Fhem/Linux dabei, aber man erlebt immer wieder was neues.

Meinen Fhem Rechner (Ubuntu) musste ich mal neu aufsetzen. Soweit auch kein Problem. Fhem gesichert, neu installiert und wieder zurückgespielt. Klappt soweit. Einzig meine Himebridge möchte nicht so wie ich es möchte.
Eingerichtet nach diesem Eintrag, also so wie immer:

https://wiki.fhem.de/wiki/Homebridge_einrichten

Das Dumme ist nur, wenn ich meinen Linuxrechner neu starte, scheint Homebridge nicht zu funktionieren.
Ein ,,ps -aux | grep -I homebridge" liefert einen Eintrag

Code Auswählen Erweitern

username    1225  1.3  0.3 861820 130744 ?       Sl   06:41   0:01 homebridge
und ein manuelles Starten mittels ,,homebridge" sagt mir, dass die Adresse bereits in Verwendung sei.

Ein ,,sudo service homebridge status" liefert dies:

 

Code Auswählen Erweitern

homebridge.service - LSB: Start daemon at boot time for homebridge
     Loaded: loaded (/etc/init.d/homebridge; generated)
     Active: active (exited) since Thu 2024-04-18 06:41:13 CEST; 1min 13s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1026 ExecStart=/etc/init.d/homebridge start (code=exited, status=0/SUCCESS)
        CPU: 24ms

Apr 18 06:41:13 s-master01 systemd[1]: Starting LSB: Start daemon at boot time for homebridge...
Apr 18 06:41:13 s-master01 su[1044]: (to username) root on none
Apr 18 06:41:13 s-master01 su[1044]: pam_unix(su-l:session): session opened for user username(ui>
Apr 18 06:41:13 s-master01 su[1044]: pam_unix(su-l:session): session closed for user username
Apr 18 06:41:13 s-master01 homebridge[1026]: Homebridge starting
Apr 18 06:41:13 s-master01 homebridge[1226]: Homebridge is not running
Apr 18 06:41:13 s-master01 systemd[1]: Started LSB: Start daemon at boot time for homebridge.

Dennoch, wenn ich meine Home Anwendung auf dem Mac mini oder der Apple Watch oder wo auch immer starte, sagen die Geräte ,,Keine Antwort". Erst nach einem

,,sudo service homebridge stop"

und

,,sudo service homebridge start"

sehe ich in der Home App auf meinen Geräten wieder alle Devices und diese funktionieren auch wieder.

Hat dazu jemand eine Idee, warum das so ist, wie es ist?

Danke schon mal

#5

Home Connect / Aw: Ergonomische Version von 4...

Letzter Beitrag von Prof. Dr. Peter Henning - 18 April 2024, 05:22:52

Der type wird bei der Initialisierung gesetzt. Wenn nur das Modul neu geladen wird, wird diese Initialisierung gar nicht ausgeführt.

Bitte als erstes: In der Device-Detailansicht auf den DEF-Link klicken und dann mit "modify hcconn BOSCH-KIF81HOD0-68A40E8EB085" bestätigen. Wenn das nicht hilft, FHEM mal neu starten.

LG

pah

#6

SVG / Plots / logProxy / Aw: Use of uninitialized value...

Letzter Beitrag von WolfgangV - 18 April 2024, 00:33:37

Ok,

hier also nochmal der aktuelle Code:

Code Auswählen Erweitern

# Created by FHEM/98_SVG.pm, 2024-04-14 23:33:53
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Anwesenheit Wohnbereichszonen'
set ytics
set y2tics
set grid
set ylabel "an"
set y2label "aus"
set yrange [0:3]

#SVG_FileLog_Anwesenheit_Esszimmer 3:Anwesenheit_Esszimmer.*::$fld[2]=~/on/?0.8:0
#SVG_FileLog_Anwesenheit_Wohnzimmer 3:Anwesenheit_Wohnzimmer.*::$fld[2]=~/on/?1.8:1
#SVG_FileLog_Anwesenheit_Kueche 3:Anwesenheit_Kueche.*::$fld[2]=~/on/?2.8:2

plot "<IN>" using 1:2 axes x1y2 title 'Anwesenheit Esszimmer' ls l0 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'Anwesenheit Wohnzimmer' ls l2 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'Anwesenheit Küche' ls l5 lw 1 with steps
Benötigst du noch irgendwas, um den Fehler zu lokalisieren?

Gruß


Wolfgang

#7

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Bison - 18 April 2024, 00:09:21

@Bison,

wird das Set-Kommando "on" eigentlich ausgeführt wenn du manuell im HM-Device ausführst?

Ja es wird sogar ein und ausgeschaltet.

Der Consumer ist so definiert.

Code Auswählen Erweitern

STD_AKT_1_Pwr type=heater power=250 switchdev=STD_AKT_1_Sw mode=can icon=Ventilator_wind on=on off=off swstate=state:.*on:*:.*off.* asynchron=1 notbefore=10 notafter=18 locktime=900:900 auto=1 pcurr=power:W:250 etotal=energy:Wh interruptable=1

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Bison - 18 April 2024, 00:07:05

Was ich aktuelle sehe ist dass jede 1-2 Sekunden ein Schaltbefehl ausgeführt wird:

2024.04.16 10:38:27 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:27 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:29 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:29 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current Context is >switch off< => swoffcond: 0, off-command: off
2024.04.16 10:38:29 1: SolarForecast DEBUG> consumer "01" - current planning state: starting
2024.04.16 10:38:30 1: SolarForecast DEBUG> ############### consumerSwitching consumer "01" ###############
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - general switching parameters => auto mode: 1, current Consumption: -100 W, nompower: 250, surplus: 331 W, planstate: switching on:, starttime: 16.04.2024 10:15:42
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - isInLocktime: 0
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - current Context is >switch on< => swoncond: 1, on-command: on
2024.04.16 10:38:30 1: SolarForecast DEBUG> consumer "01" - device >STD_AKT_1_Sw< is used as switching device
2024.04.16 10:38:30 2: SolarForecast - switching Consumer 'Entfeuchter' to 'on' (Automatic = 1)

Erkannt wird der Status nicht.
Wie steht dein Attribut ctrlInterval?

Hallo Heiko,

das Attribut ctrlInterval ist nicht gesetzt.

Gruß

#9

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 17 April 2024, 23:44:03

@Bison,

wird das Set-Kommando "on" eigentlich ausgeführt wenn du manuell im HM-Device ausführst?

#10

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von hazelnut - 17 April 2024, 23:26:13

Hi,

Illegal division by zero at ./FHEM/76_SolarForecast.pm line 8206.

Die mögliche "Devsion by zero" habe ich nun abgefangen bzw. prüfe nun auch eine fehlerhafte Definition des Schüssels cap.
Die V ist eingecheckt und morgen früh im Update. Die V liegt auch in meinem contrib für Eilige.

So, Update ist durch ...

Code Auswählen Erweitern

Internals:
   FUUID      65eaf512-f33f-4c82-2174-7dc6bc03d704f24c
   FVERSION   76_SolarForecast.pm:v1.17.8-s28799/2024-04-16
   MODE       Automatic - next Cycletime: 23:14:56
   MODEL      DWD
   NAME       PV_Forecast
   NR         75
   NTFY_ORDER 50-PV_Forecast
   STATE      updated
   TYPE       SolarForecast
   eventCount 4
   HELPER:
     FW         WEB
     PACKAGE    FHEM::SolarForecast
     SPGDETAIL 
     SPGDEV     PV_Forecast
     SPGROOM   
     VERSION    1.17.8
     VERSION_API unused
     VERSION_CTZ 1.0.0
     VERSION_ErrCodes unused
     VERSION_SMUtils 1.27.2
...
Die Auslastung vom Pi hält sich in Grenzen ...

Code Auswählen Erweitern

average: 0.16, 0.18, 0.18
... und in der Logdatei steht:

Code Auswählen Erweitern

...
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:12:36 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:13:47 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:14:58 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:16:08 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:17:19 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step1 - compare with SoC history -> new Target: 55 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step2 - note remaining days until care SoC (20 days) -> Target: 55 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step3 - note charging probability -> Target: -279 % (new target < current Target SoC 60)
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step4 - observe low/up limits -> Target: 60 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step5 - rounding the SoC to steps of 5 -> Target: 60 %
2024.04.17 23:18:30 1: PV_Forecast DEBUG> SoC calc Step6 - force charging request: no (Battery is sufficiently charged)...
Der Bauch sagt ... dass das so aussehen könnte

Dann werde ich das mal die Tage beobachten und schauen, wie ich am sinnvollsten weitermache.

Dir erst einmal vielen Dank und ich hoffe die Infos helfen dir.

Gutes Nächtle

Hazel