Hauptmenü

Neueste Beiträge

#51
FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version ...
Letzter Beitrag von Ryker - 24 April 2024, 08:41:16
Ja, das "deviceinfo" Attribute hatte ich mir auch schon angeschaut, aber das steuert ja nur, wie Geräte angezeigt werden die gerade online sind.
Offline-Geräte (die nicht mehr in den readings erwähnt werden) betrifft das nicht. Und genau das ist aber der springende Punkt.
Hier erscheint im ReadingsProxy, dann aber zusätzlich zum "inactive" auch noch die IP-Adresse. Ich weiß auch nicht woher der ReadingsProxy das holt. Iwie muss das das Fritzbox-Modul ja liefern, obwohl kein Reading dazu da ist.

Aber wie gesagt, Ich filtere jetzt im ReadingsProxy im valueFN alles weg nach dem Wort "inactive" sobald der Status den Wert "inactive" beinhaltet. Damit klappt meine Anwesenheitserkennung anhand der an der Fritzbox angemeldeten Handys wieder.
#52
TabletUI / Aw: FTUI-2 Chart wird nicht ak...
Letzter Beitrag von Nobby1805 - 24 April 2024, 08:25:38
Hallo eki,

das sieht jetzt sehr gut aus ... Danke!

Dann noch eine Frage, wie bekomme ich eine Skalierung wie im Simplechart hin? Normalerweise von 21 bis 23, aber wenn der Bereich über- oder unterschritten wird z.B. von 20 bis 23 ?

Viele Grüße
Norbert
#53
Automatisierung / Probleme nach FHEM update bei ...
Letzter Beitrag von R1F800 - 24 April 2024, 08:23:26
Moin zusammen.

Ich habe ein Problem mit meinem FRM_IN der einen INTERRUPT eines MCP23017 ausliest.
Bisher habe ich auf dem Device mit einem Userreading reagiert, um entsprechend eine neue Initialiiserung durchzuführen. Dies klappt aber seit einem Update so nicht mehr : defmod MCP0x20_INTA FRM_IN 7
attr MCP0x20_INTA IODev FIRMATA
attr MCP0x20_INTA activeLow yes
attr MCP0x20_INTA internal-pullup on
attr MCP0x20_INTA room FIRMATA
attr MCP0x20_INTA stateFormat reading
attr MCP0x20_INTA userReadings pullX20a {fhem "get MCP0x20"}
attr MCP0x20_INTA verbose 1

setstate MCP0x20_INTA off
setstate MCP0x20_INTA 2024-04-20 09:48:45 IODev FIRMATA
setstate MCP0x20_INTA 2024-04-24 08:10:16 reading off
setstate MCP0x20_INTA 2024-04-20 09:48:45 state Initialized
#54
Solaranlagen / Aw: [98_Fronius.pm] Fronius AP...
Letzter Beitrag von hugomckinley - 24 April 2024, 08:03:38
Ich habe seit kurzem den Smartmeter im Einsatz und jetzt binnen 4 Wochen zweimal die Situation gehabt, dass plötzlich keine Readings mehr kommen. Weder ein modify oder ein defmod haben etwas gebracht. Der WR bleibt im Status initialize.
Ich verwende die Version v0.0.11c vom Modul. Eigentlich hat nach den letzten Änderungen vom Modul alles funktioniert und jetzt mit dem neuen WR (Symo 15.0 statt 6.0) und Smartmeter habe ich wieder dieses sporadischen Ausfälle, die nur ein Neustart von FHEM behebt.

Ein verbose=4 bringt folgende Logeinträge:
2024.04.24 06:06:04 4: [WR] [fronius_GetMeterRealtimeData] Timer 60
2024.04.24 06:06:06 4: [WR] [fronius_GetInverterRealtimeData] Timer 60
2024.04.24 06:06:10 4: [WR] [fronius_StartUp]
2024.04.24 06:06:10 4: [WR] [fronius_StartUp] clearHeadData
2024.04.24 06:06:10 4: [WR] [fronius_StartUp] RemoveInternalTimer
2024.04.24 06:06:10 4: [WR] [fronius_StartUp] InternalTimer Statische Daten
2024.04.24 06:06:10 4: [WR] [fronius_StartUp] InternalTimer Realtime Daten
2024.04.24 06:06:10 4: [WR] [fronius_StartUp] InternalTimer Archive Daten - 120
2024.04.24 06:06:10 4: [WR] [fronius_StartUp] done
2024.04.24 06:06:10 4: [WR] [fronius_SendCommand] [GetAPIVersionInfo] START
2024.04.24 06:06:10 4: [WR] [fronius_SendCommand] [GetAPIVersionInfo] PushToCmdQueue SendURL=http://192.168.64.94/solar_api/GetAPIVersion.cgi
2024.04.24 06:06:15 4: [WR] [fronius_SendCommand] [GetActiveDeviceInfo] START
2024.04.24 06:06:15 4: [WR] [fronius_SendCommand] [GetActiveDeviceInfo] NOT PushToCmdQueue ERROR=Fronus API Base URL not set!
2024.04.24 06:06:15 4: [WR] [fronius_SendCommand] [GetActiveDeviceInfo] re-init fronius_GetAPIVersionInfo
2024.04.24 06:06:20 4: [WR] [fronius_SendCommand] [GetPowerFlowRealtimeData] START
2024.04.24 06:06:20 4: [WR] [fronius_SendCommand] [GetPowerFlowRealtimeData] NOT PushToCmdQueue ERROR=Fronus API Base URL not set!
2024.04.24 06:06:20 4: [WR] [fronius_SendCommand] [GetPowerFlowRealtimeData] re-init fronius_GetAPIVersionInfo
2024.04.24 06:06:20 4: [WR] [fronius_GetPowerFlowRealtimeData] Timer 60
2024.04.24 06:06:22 4: [WR] [fronius_GetStorageRealtimeData] Timer 60
2024.04.24 06:06:24 4: [WR] [fronius_GetMeterRealtimeData] Timer 60
2024.04.24 06:06:26 4: [WR] [fronius_GetInverterRealtimeData] Timer 60
2024.04.24 06:06:30 4: [WR] [fronius_StartUp]
2024.04.24 06:06:30 4: [WR] [fronius_StartUp] clearHeadData
2024.04.24 06:06:30 4: [WR] [fronius_StartUp] RemoveInternalTimer
2024.04.24 06:06:30 4: [WR] [fronius_StartUp] InternalTimer Statische Daten
2024.04.24 06:06:30 4: [WR] [fronius_StartUp] InternalTimer Realtime Daten
2024.04.24 06:06:30 4: [WR] [fronius_StartUp] InternalTimer Archive Daten - 120
2024.04.24 06:06:30 4: [WR] [fronius_StartUp] done
2024.04.24 06:06:30 4: [WR] [fronius_SendCommand] [GetAPIVersionInfo] START
2024.04.24 06:06:30 4: [WR] [fronius_SendCommand] [GetAPIVersionInfo] PushToCmdQueue SendURL=http://192.168.64.94/solar_api/GetAPIVersion.cgi
2024.04.24 06:06:35 4: [WR] [fronius_SendCommand] [GetActiveDeviceInfo] START
2024.04.24 06:06:35 4: [WR] [fronius_SendCommand] [GetActiveDeviceInfo] NOT PushToCmdQueue ERROR=Fronus API Base URL not set!
2024.04.24 06:06:35 4: [WR] [fronius_SendCommand] [GetActiveDeviceInfo] re-init fronius_GetAPIVersionInfo
2024.04.24 06:06:40 4: [WR] [fronius_SendCommand] [GetPowerFlowRealtimeData] START
2024.04.24 06:06:40 4: [WR] [fronius_SendCommand] [GetPowerFlowRealtimeData] NOT PushToCmdQueue ERROR=Fronus API Base URL not set!
2024.04.24 06:06:40 4: [WR] [fronius_SendCommand] [GetPowerFlowRealtimeData] re-init fronius_GetAPIVersionInfo
2024.04.24 06:06:40 4: [WR] [fronius_GetPowerFlowRealtimeData] Timer 60
2024.04.24 06:06:42 4: [WR] [fronius_GetStorageRealtimeData] Timer 60
2024.04.24 06:06:44 4: [WR] [fronius_GetMeterRealtimeData] Timer 60
2024.04.24 06:06:46 4: [WR] [fronius_GetInverterRealtimeData] Timer 60

Es sieht genauso aus, wie das Timerproblem von "damals", wo die Timer nicht gesetzt wurden, wenn der WR im Standby ist.

Grüße
Hugo
#55
Automatisierung / Aw: [ASC] - Merkwürdiges Venti...
Letzter Beitrag von Reinhard.M - 24 April 2024, 08:01:37
Genau so ist es. Für höchsten 1s fährt das Rollo korrekterweise hoch. Dann kommt aber von ASC der Befehl "fahre runter". Im Device wird das Rollo als "aktiv runter fahrend" signalisiert. Das dauert bis die eingestellten 24% erreicht sind. Korrekterweise stoppt ASC dann die Fahrt (genauer gesagt, die Anzeige der Fahrt, es bewegt sich ja nichts mehr) und alles ist grün. Die Höhe wird mit 24% angezeigt. Mit "Comfort open" passiert es nicht! Und wie gesagt, "Copy - Paste" ohne Änderung. Vorher lief es Jahre ohne Probleme. Sehr merkwürdig...
#56
Automatisierung / Aw: [ASC] - Merkwürdiges Venti...
Letzter Beitrag von CoolTux - 24 April 2024, 07:44:59
Bin nicht ganz schlau aus Deiner Beschreibung geworden.
Fährt das Rollo beim Fenster öffnen wirklich auch hoch?

Um dann nach 1-2 Sekunden sofort wieder zu schliesen?
#57
Solaranlagen / Aw: Erfahrungen mit der Anbind...
Letzter Beitrag von miguelito - 24 April 2024, 07:39:56
Moin,

Zitat von: miguelito am 29 März 2024, 11:41:40Nun zur Bitte: Könnte jemand mit dem Meter einen Trace für mich machen, wenn der Meter beim Wechselrichter "angelernt" wird? D.h in der FusionSolar App - "Gerät einrichten" - Anmelden als Installateuer, Grundeinstellungen -> weiter nach Geräteverwaltung (siehe Bild unten) und dann einfach beim Punkt "+ Stromzähler" nochmal Euren Stromzähler auswählen (DTSU666-H). Dann sollten die Nachrichten rausgehen mit denen der WR den PM identifiziert.
Erinnert Euch an meine vorherigen Nachrichten: Es geht da eine Abfrage an Register 0x07D1 (2001) raus - Für dieses Register habe ich jetzt natürlich keine Doku - was da kommen sollte -> Trace :)

Im sun.store gibts den Huawei DTSU-666H um 99.- Werd' mir in der nächsten Zeit mal so einen holen zum reverse engineeren. Dann muss ich keinen von Euch quälen mir einen trace von der Einrichtung des DTSU666 am Inverter zu machen. Die billigste Lösung wäre dann den DTSU-666 zusätzlich in den Zählerschrank zu schrauben. Damit hat der Sun Inverter seinen eigenen Meter für die Batteriesteuerung und Ruhe ist. Aber eigentlich möchte ich schon zuerst den Weg probieren, mit der bereits vorhandenen FHEM Lösung / Auslesen des Smartmeters Energieversorger auch den Sun Inverter mit Daten zu versorgen.
#58
Unterstützende Dienste / Aw: 95_Shares.pm erweitert um ...
Letzter Beitrag von ToKa - 24 April 2024, 07:39:46
Moin,

das ist genau die gleiche Fehlermeldung wie sie bei mir auch auftaucht.

Ich konnte mir nur damit behelfen, dass ich das Cookie vom Win PC übernommen habe und yahoo_jason modifiziert habe.

VG
Torsten
#59
MQTT / Aw: Vebindung zu Zigbee2Mqtt, ...
Letzter Beitrag von frober - 24 April 2024, 06:54:03
Ja, wie auch immer, auf das erste angelegte MQTT2_Device.

Ich habe aber gerade gesehen, dass du es auf dem manuell angelegten angewendet hast.

Wenn das nicht funktioniert, alles bis auf den Client löschen. Autocreate aktivieren und dann auf das erste automatisch angelegte Device das Bridge Template anwenden. Dann sollte es funktionieren.
#60
FHEMapp / Aw: FHEMApp4 - Beta Version
Letzter Beitrag von binford6000 - 24 April 2024, 05:51:07
Moin Benni,
ja FHEM läuft unter dem User "fhem" und der Download läuft auch problemlos durch:

fhem@pi0:~$ wget -v https://api.github.com/repos/jemu75/fhemApp/tarball/v4.0.38-beta
--2024-04-24 05:39:10--  https://api.github.com/repos/jemu75/fhemApp/tarball/v4.0.38-beta
Auflösen des Hostnamens api.github.com (api.github.com)... 140.82.121.5
Verbindungsaufbau zu api.github.com (api.github.com)|140.82.121.5|:443 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 302 Found
Platz: https://codeload.github.com/jemu75/fhemApp/legacy.tar.gz/refs/tags/v4.0.38-beta [folgend]
--2024-04-24 05:39:11--  https://codeload.github.com/jemu75/fhemApp/legacy.tar.gz/refs/tags/v4.0.38-beta
Auflösen des Hostnamens codeload.github.com (codeload.github.com)... 140.82.121.9
Verbindungsaufbau zu codeload.github.com (codeload.github.com)|140.82.121.9|:443 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: nicht spezifiziert [application/x-gzip]
Wird in »v4.0.38-beta« gespeichert.

v4.0.38-beta                     [                           <=>                 ]  10,15M  2,25MB/s    in 5,4s   

2024-04-24 05:39:17 (1,89 MB/s) - »v4.0.38-beta« gespeichert [10648478]

Falls es nochmal auftreten sollte zB. beim nächsten Update zu Stable melde ich mich wieder.

Danke und VG,
Sebastian