fhempy: tuya (lokal)

[Gisbert]

Hallo zusammen,

ich hab meinen Fhem-Server von Bullseye auf Bookworm (Debian 12) upgedatet.
Jetzt funktioniert fhempy nicht mehr.

Wenn ich auf dem Server

Code Auswählen Erweitern

pip3 install --upgrade fhempy eingebe, erhalte ich

Code Auswählen Erweitern

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
Im fhempy-log steht vergleichbares drin:

Code Auswählen Erweitern

2023-11-08 16:57:24,125 - ERROR    - __main__: Failed to load fhempy
Traceback (most recent call last):
  File "/opt/fhem/FHEM/bindings/python/bin/fhempy", line 139, in <module>
    import fhempy.lib.fhem_pythonbinding as fpb
ModuleNotFoundError: No module named 'fhempy'
2023-11-08 16:57:24,131 - INFO     - __main__: Attempting install of fhempy>=0.1.462
2023-11-08 16:57:24,899 - ERROR    - __main__: Unable to install package fhempy>=0.1.462: error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
   
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
   
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
   
    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
2023-11-08 16:57:24,899 - ERROR    - __main__: Failed to install fhempy, exit now...

Hat jemand tuya / fhempy auf einem Debian 12 (Bookworm) erfolgreich zum Laufen gebracht?

Viele Grüße
Gisbert

PS: Ich hab ein Backup mit Debian 11 eingespielt, da ich bisher keine Lösung gefunden habe.

[hglaeser]

Hallo,

ich habe einen WiFi-Türkontakt-Sensor im FHEM Local eingebunden. Er funktioniert soweit und die Eigenschaft doorcontact_state ändert sich im FHEM auch, wenn ich den Kontakt schließe bzw. öffne.

ABER: Der Sensor geht nach wenigen Sekunden ohne Statusänderung (Schließen/Öffnen) in einen Stromsparmodus und ist dann bis zur nächsten Statusänderung nicht mehr mit dem WLAN verbunden. Erst bei der nächsten Statusänderung baut der Sensor die WLAN-Verbindung wieder auf (dauert ca. 2-3 Sekunden) und meldet die Statusänderung dann an die Tuya-Cloud. Die Smart Life-App bekommt die Statusänderung auch immer mit, wenn auch eben mit 2-3 Sekunden Verzögerung. Das stört mich aber nicht.

Nur das FHEM-Modul "Tuya Local" bekommt in diesem Fall von der Statusänderung leider überhaupt nichts mit. Öffne bzw. schließe ich den Sensor innerhalb von ca.15 Sekunden mehrmals, dann bekommt Tuya Local das nach ca. 6-8 Statusänderungen mit, aber eben nicht die erste Statusänderung.

Nun wollte ich aber die Fenster/Türen nicht immer erst 15 Sekunden lang öffnen und schließen müssen, damit FHEM eine Aktion ausführt

Ist dieses Verhalten prinzipbedingt so oder kann ich das noch irgendwie "wegkonfigurieren"? An dem Stromsparmodus des Sensors möchte ich aber nichts ändern, da dessen Batterien mehrere Monate halten.

Vielen Dank für Eure Antwort.

Holger

[traders-banquet]

Hallo,
ich habe meine Fhem Installation auf Debian Bookworm. Hier wird wohl pip nicht mehr verwendet, daher auch die Fehlermeldung des Kollegen im vorletzten Beitrag. Mit --break-system-packages lassen sich diese dann aber installieren.
Nun habe ich meinen fhempyserver_1533 laufen, meinen fhempy_local Version 0.1670. Um an meine Geräte zu kommen benötige ich noch den Tuya_Cloud_Connector.
Diesen habe ich nun unzählig oft versucht einzurichten mit :
define tuya_cloud_connector fhempy tuya_cloud setup xxxxxxxxxxxxxxxxxxxx XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX xxxx@xxx.xx        XXXXXXXXXXXXXXX        smartlife Europe
                                                    Access ID/Client ID  Access Secret/Client Secret      Smartlife Login    smartlife Passwort

Ich erhalte aber immer nur :
2023-11-10 17:08:43,772 - ERROR    - fhempy_tuya_cloud_connector: Tuya login error response: {'code': 1106, 'msg': 'permission deny', 'success': False, ........

Ich habe das Kennwort in der Tuya App nun schon geändert, da hier wohl die meissten Suchen nach dem Fehler damit gelöst wurden.
Aktuell weiss ich mir nicht mehr zu helfen.

Hier die Logausgabe wenn ich den fhempyserver neu starte, t und tid habe ich heraus genommen :

Code Auswählen Erweitern

r2023-11-10 17:50:10,292 - INFO     - fhempy.lib.fhem_pythonbinding: Shutdown initiated...
2023-11-10 17:50:10,292 - INFO     - fhempy.lib.fhem_pythonbinding: All modules successfully undefined!
2023-11-10 17:50:10,292 - INFO     - websockets.server: server closing
2023-11-10 17:50:15,305 - INFO     - fhempy.lib.fhem_pythonbinding: Starting fhempy 0.1.670...
2023-11-10 17:50:15,306 - INFO     - fhempy.lib.fhem_pythonbinding: Waiting for FHEM connection
2023-11-10 17:50:15,314 - INFO     - websockets.server: server listening on 0.0.0.0:15733
2023-11-10 17:50:25,452 - INFO     - websockets.server: connection open
2023-11-10 17:50:25,452 - INFO     - fhempy.lib.fhem_pythonbinding: Incoming FHEM connection: 127.0.0.1
2023-11-10 17:50:25,927 - ERROR    - fhempy_tuya_cloud_connector: Tuya login error response: {'code': 1106, 'msg': 'permission deny', 'success': False, 't': , 'tid': ''}


Kann sich jemand einen Reim darauf machen ?

[Snocksman]

Hi !

Ich habe mir so eine nette Infrarotheizung fürs Bad gekauft und das Teil ist ein tuya Wifi Device. In der Tuya App ist alles eingerichtet und funktioniert, fhempy ist auch eingerichtet und funktioniert und auch die Infrarotheizung wurde gefunden. Nun steht in dem angelegten Device aber noch die Meldung:"STATE attr localkey required" und da stelle ich mich wahrscheinlich gerade einfach ein bisschen blöde an... Wo finde ich diesen "localkey" ?

Hat sich erledigt ! Habs gefunden !!! Und funktioniert. 

[Snocksman]

Jetzt habe ich aber scheinbar doch noch ein Problem...

Die ganze Sache läuft soweit bei mir und ich kann die Infrarotheizung steuern... Nach längerer Zeit (+- 1 Stunde) bekomme ich aber beim tuya_system und bei meinem Infrarotheizungs-Device angezeigt, dass der fempy Server Offline wäre... Das fempy_local und fempy_server Device wird mir aber weiterhin mit dem grünen Punkt angezeigt (sollte also laufen...).

Ein restart des fempyserver Devices hilft auch nicht weiter, sondern nur ein komplettes neustart des Raspis.

Was kann das sein...?

[TheTrumpeter]

Ich habe eine Frage in Zusammenhang mit dem Attribut "event-min-interval".
Das scheint bei meinen Steckdosen nicht ausgelöst zu werden.

Ich möchte die Readings "cur_current", "cur_power" und "cur_voltage" mindestens alle 15min im Log haben (für Plots). Dazu habe ich wie ich es aus anderen Geräten gewohnt bin, das Attribut "event_min_interval" auf "cur.*:900" gesetzt. Allerdings fehlen die Einträge im Log.
Mir ist aufgefallen, dass beim automatischen Anlegen des Geräts beispielsweise ein Attribut "dp_19" auf "cur_power" gesetzt wurde. Nun habe ich auch ausprobiert dieses Reading "dp_19", was offenbar automaisch zu "cur_power" umbenannt wird, in "event-min-interval" zu ergänzen, also "cur.*:900,dp_19:900". Das ändert aber nix.

"event-on-change-reading" funktioniert tadellos und die Einträge im Log sind auch vorhanden, solange sich die Werte ändern. Was mache ich falsch?