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?

[dero]

Ich mache gerade meine ersten Versuche mit dem tollen Plugin. Scannen funktioniert. Wenn ich allerdings auf "createdevice" klicke, kommt im Log:

```
2023-12-05 11:03:47,299 - ERROR    - tuya_local_bf2e82b52cbf71e2bfosgd: Failed to connect to device
Traceback (most recent call last):
  File "/opt/fhem/.local/lib/python3.9/site-packages/fhempy/lib/tuya/tuya.py", line 563, in setup_connection
    self._connected_device = await asyncio.wait_for(connect_fct, timeout=15)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 481, in wait_for
    return fut.result()
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/__init__.py", line 206, in connect
    await device.start_socket()
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/core.py", line 917, in start_socket
    raise ex
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/core.py", line 905, in start_socket
    await self._negotiate_session_key()
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/core.py", line 1464, in _negotiate_session_key
    rkey = await self._send_receive_quick(
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/core.py", line 1090, in _send_receive_quick
    self._encode_message(payload)
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/core.py", line 1589, in _encode_message
    payload = self.cipher.encrypt(payload, False)
  File "/opt/fhem/.local/lib/python3.9/site-packages/aiotinytuya/core.py", line 281, in encrypt
    cipher = AES.new(self.key, mode=AES.MODE_ECB)
  File "/opt/fhem/.local/lib/python3.9/site-packages/Crypto/Cipher/AES.py", line 228, in new
    return _create_cipher(sys.modules[__name__], key, mode, *args, **kwargs)
  File "/opt/fhem/.local/lib/python3.9/site-packages/Crypto/Cipher/__init__.py", line 79, in _create_cipher
    return modes[mode](factory, **kwargs)
  File "/opt/fhem/.local/lib/python3.9/site-packages/Crypto/Cipher/_mode_ecb.py", line 216, in _create_ecb_cipher
    cipher_state = factory._create_base_cipher(kwargs)
  File "/opt/fhem/.local/lib/python3.9/site-packages/Crypto/Cipher/AES.py", line 90, in _create_base_cipher
    raise ValueError("Incorrect AES key length (%d bytes)" % len(key))
ValueError: Incorrect AES key length (13 bytes)
```

Hat jemand eine Idee?

[TheTrumpeter]

ValueError: Incorrect AES key length (13 bytes)

Sicher, dass Du das "tuya_system"-Device richtig angelegt hast?

[satprofi]

Hallo.
Bei action gestern 5m Streifen gekauft, klappt damit sogar Farbänderung, etc. zu steuern.

LG

[Xsantos]

Hallo,
erstmal vielen Dank für die tolle Arbeit! Ich habe über 50 Tuya-Geräte im Einsatz und die meisten funktionieren ohne Probleme.
Eine kleine Sache habe ich allerdings:
Ich habe drei Flutlichter und kann die Farbe über Fhem nicht einstellen.
Es gibt zwar die Auswahl: "colour_data" aber beim setzen ändert sich nicht das Reading.
Wenn ich in der "Smart-Life App" z.B. die Farbe Rot einstelle, dann ändert sich das Reading "colour_data" sofort auf "000003".
Wenn ich es aber separat eingebe: set XXXXX colour_data 000003 , bleibt der Wert unverändert.

Es wäre super wenn einer/eine mir helfen kann.

Vielen Dank und schöne Feiertage,
Marco

[TheTrumpeter]

Ich habe ein Problem mit dem automatischen Update...

fhempy_local "hängt" schon länger auf der 0.1.670 fest. Das hat mich bisher nicht gestört, weil alles funktioniert hat.
Gestern habe ich dann ein generelles FHEM-Update gemacht, dann ging erstmal gar nichts ("server offline"). Im Logfile war die vermeintliche Ursache rasch gefunden, mittels "apt-get install python3-venv" war der Server dann auch rasch wieder online. fhempy_local hat sich trotzdem auch nach FHEM-Neustart nicht mehr verbunden.
Ich habe dann versucht ein Update mittels "pip3 install --upgrade fhempy" zu machen so wie es hier wohl schonmal erfolgreich war, https://forum.fhem.de/index.php?topic=118803.0
Während die Installation noch lief, hat sich fhempy_local auch schon wieder verbunden. Ob tatsächlich "pip 3 install ..." dabei geholfen hat oder ich einfach nur nicht lange genug gewartet habe, kann ich nicht sagen. Auf den ersten Blick scheint wieder alles zu funktionieren, nur ein Update von fhempy_local klappt weiterhin nicht.

Der Status hing immer in "restart... please wait", auch ein FHEM-Neustart änderte daran nichts. Ich habe nun FHEM nochmal neu gestartet und erneut das versucht fhempy_local zu aktualisieren. Es ging zwar wieder nicht, aber zumindest schaut der Status wieder "normal" aus.
Hier das Logfile von heute (FHEM-Neustart und dann Update-Versuch):

Code Auswählen Erweitern

Activating virtual environment...OK
2023-12-30 08:58:29,764 - INFO     - fhempy.lib.fhem_pythonbinding: Starting fhempy 0.1.670...
2023-12-30 08:58:29,766 - INFO     - fhempy.lib.fhem_pythonbinding: Waiting for FHEM connection
2023-12-30 08:58:29,849 - INFO     - websockets.server: server listening on 0.0.0.0:15733
2023-12-30 08:58:35,715 - INFO     - websockets.server: connection open
2023-12-30 08:58:35,717 - INFO     - fhempy.lib.fhem_pythonbinding: Incoming FHEM connection: 127.0.0.1
2023-12-30 09:06:39,580 - INFO     - fhempy.lib.fhem_pythonbinding: Start update...
2023-12-30 09:06:39,582 - INFO     - fhempy.lib.pkg_installer: Attempting install of fhempy
2023-12-30 09:06:57,066 - INFO     - fhempy.lib.pkg_installer: Successfully installed fhempy update!
2023-12-30 09:06:57,088 - INFO     - fhempy.lib.fhem_pythonbinding: Restart initiated...
2023-12-30 09:06:57,093 - INFO     - fhempy.lib.fhem_pythonbinding: All modules successfully undefined!
2023-12-30 09:06:57,094 - INFO     - websockets.server: server closing
2023-12-30 09:07:07,104 - INFO     - websockets.server: connection closed
2023-12-30 09:07:07,106 - INFO     - websockets.server: server closed
2023-12-30 09:07:07,110 - INFO     - fhempy.lib.fhem_pythonbinding: Exit 1
Activating virtual environment...OK
2023-12-30 09:07:09,965 - INFO     - fhempy.lib.fhem_pythonbinding: Starting fhempy 0.1.670...
2023-12-30 09:07:09,968 - INFO     - fhempy.lib.fhem_pythonbinding: Waiting for FHEM connection
2023-12-30 09:07:10,054 - INFO     - websockets.server: server listening on 0.0.0.0:15733
2023-12-30 09:07:17,243 - INFO     - websockets.server: connection open
2023-12-30 09:07:17,245 - INFO     - fhempy.lib.fhem_pythonbinding: Incoming FHEM connection: 127.0.0.1
Kann ich fhempy_local irgendwie "manuell" aktualisieren bzw. wie kann ich den Fehler finden und lösen?

[tomhead]

Ich habe ein Problem mit dem automatischen Update...

fhempy_local "hängt" schon länger auf der 0.1.670 fest.

Hallo, bei mir das gleiche Problem, ich habe bereits mehrfach aus FHEM raus start update probiert, ebenso pip3 install --upgrade fhempy, aber trotzdem wird mir immer noch angezeigt:

Code Auswählen Erweitern

version 0.1.670
version_available 0.1.698

[tomhead]

Jetzt muss ich doch noch mal nachfragen, ob evtl. jemand ne Lösung weiss: ich bekomme keine fhempy Updates mehr, bei 0.1.670 bleibt es, obwohl mittlerweile 0.1.709 als verfügbar angezeigt wird. Habe das device fhempy_local auch schon gelöscht und wieder neu angelegt, hat aber nix gebracht.
Außerdem frage ich mich, ob das evtl. mit der python version zusammenhängen könnte, da es mir 3.7.3 in den readings angezeigt.

Code Auswählen Erweitern

python 3.7.3
release 5.10.103-v7+
state opened
system Linux
version 0.1.670
version_available 0.1.709
Python3 selber habe ich heute auf 3.12.1 auf meinem Raspberry aktualisiert (sowohl python -VV als auch python3 --version liefern Python 3.12.1 als Version, wobei mir apt policy python3 als Ergebnis "Installiert 3.7.3-1" liefert), aber wie bekomme ich python3-venv aktualisiert? Wenn ich "sudo apt install python3-venv" eingebe, kommt "python3-venv ist schon die neueste Version (3.7.3-1)". Könnt ihr mir weiterhelfen ?
VG, Tom

Update:
Jetzt läuft nach einem Neustart fhempy gar nicht mehr (denn sie wissen nicht, was sie tun , im Log kommt folgendes:

Code Auswählen Erweitern

Current thread 0x76f3c040 (most recent call first):
  <no Python frame>
Activating virtual environment...OK
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'python3'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/usr/local/lib/python3.12'
  sys._base_executable = '/usr/local/bin/python3.12'
  sys.base_prefix = '/usr/local'
  sys.base_exec_prefix = '/usr/local'
  sys.platlibdir = 'lib'
  sys.executable = '/opt/fhem/.fhempy/fhempy_venv/bin/python3'
  sys.prefix = '/usr/local'
  sys.exec_prefix = '/usr/local'
  sys.path = [
    '/usr/local/lib/python312.zip',
    '/usr/local/lib/python3.12',
    '/usr/local/lib/python3.12/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Bitte Hiiiilfe...

Update2: Hab es nun wie folgt gelöst: Habe FHEM auf einem frischen Debian (gleich mal Bullseye statt Buster verwendet) neu installiert  und dann ein 3 Tage altes FHEM Backup (vor Start der Probleme) eingespielt. Damit bin ich jetzt automatisch auf phyton 3.9.2. Um trotz Backup fhempy wieder zum laufen zu bekommen, musste ich das fhempy_local Device entfernen, den Ordner /opt/fhem/.fhempy komplett löschen und dann das Device wieder neu anlegen. Nach einem FHEM Neustart läuft es jetzt wieder, auch auf der aktuellsten Version 0.1.714

[TheTrumpeter]

Bitte Hiiiilfe...

Ich habe vor ein paar Tagen auch nochmal versucht das Problem zu lösen.
Was ich herausgefunden habe:
Falls Du Raspbian nutzt, müsste es auch bei Dir so sein:
In den Ordnern /opt/fhem/.fhempy/fhempy_venv/lib/python3.7/site-packages/fhempy/ und /opt/fhem/.fhempy/fhempy_venv/lib64/python3.7/site-packages/fhempy/ finden sich genau die Dateien vom github https://github.com/fhempy/fhempy/tree/master/FHEM/bindings/python/fhempy/lib (bzw. eben die alte Version, ich habe einzelne Dateien, die sich seither geändert haben, stichprobenartig geprüft).
Außerdem liegt dort bei mir eine Ebene höher (/opt/fhem/.fhempy/fhempy_venv/lib/python3.7/site-packages/) noch ein Ordner "fhempy-0.1.670.dist-info" mit irgendwelche Meta-Informationen.

Ich VERMUTE, dass es zum Reparieren des Problems ausreichen würde, die beiden obigen Ordner (site-packages/fhempy/) einfach mit den Dateien vom github zu überschreiben.
Ursprünglich wollt' ich das auch tun, aber dann hat mich doch der Mut verlassen, zumal ich die ganzen neuen Features aktuell nicht benötige.
(Vielleicht "fehlt" dann auch das Zeug aus der "dist-info", deren Herkunft ich in github leider nicht ausfindig machen konnte.)

[tomhead]

@TheTrumpeter: Danke für deine Hilfe, ich hatte es mittlerweile so gelöst, dass ich FHEM auf einem frischen Debian (gleich mal Bullseye statt Buster verwendet) neu installiert habe und dann ein 3 Tage altes FHEM Backup (vor Start der Probleme) eingespielt habe. Damit bin ich jetzt automatisch auf phyton 3.9.2. Um trotz Backup fhempy wieder zum laufen zu bekommen, musste ich das fhempy_local Device entfernen, den Ordner /opt/fhem/.fhempy komplett löschen und dann das Device wieder neu anlegen. Nach einem FHEM Neustart läuft es jetzt wieder.
Danke und Grüße