Autor Thema: [UMFRAGE] Lösungsansätze für Geräte die in FHEM nicht unterstützt werden  (Gelesen 650 mal)

Offline ole1986

  • New Member
  • *
  • Beiträge: 11
Mich interessiert derzeit, wie oft es bei Euch unvermeidlich war FHEM ausweichend einzusetzen, indem beispielsweise eigene Skripte alternative Lösungen geschaffen wurden um die Geräte so zu steuern oder zu erfassen wie es eben erfordert.

Ich bin davon überzeugt das diese Umfrage ein recht interessantes Ergebnis liefern könnte

Vielen Dank an Alle die daran Teilnehmen.

Offline abc2006

  • Sr. Member
  • ****
  • Beiträge: 818
Wenn ich einen Kommentar dazu loswerden darf: eigentlich würde ich für die beiden ersten Punkte ein "ja" abgeben.... ob ich jetzt selbst ein Modul schreibe (z.B. um eine vorhandene Schnittstelle aktiv abzufragen) oder ob ich externe Scripte einsetze (z.b. über Python einen Temperatursensor, der dann an localhost:7072 ein "set dummy $temperature" absetzt, oder einen arduino, der einen http-link aufruft), ist recht identisch.
Obwohl, auch Punkt 3 habe ich tatsächlich schon gemacht, war aber nur, um eben die Kommunikation herauszufinden, damit ich ein eigenenes Modul schreiben kann.
Habe dann die Schnittstelle mitgesnifft und so die richtigen Codes herausgefunden, um mit dem Gerät zu kommunizieren.

Bin gespannt auf weitere Kommentare ...
Stephan

 
FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Lippie

  • New Member
  • *
  • Beiträge: 35
Hallo,

Da das harmony-Device keine eigenen huebridge-Smarthome-Geräte simulieren kann, nutze ich die HA-Bridge mit HUEBridge und HUEDevice, um in meiner Harmony-Fernbedienung Lampen, Jalousien und die Solltemperatur unserer Heizung anzuzeigen und zu steuern.

Leider ist dieser Umweg aufgrund von zu viel Netzwerkkommunikation recht langsam.

Den HA-Bridge Quellcode gibt's ja in Github. Mir selbst fehlt leider das KnowHow, eine virtuelle HUE für FHEM zu programmieren.

VG
Sebastian


Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3593
Ich versuche solche Probleme zu vermeiden und recherchiere vor dem Kauf welches Produkt von FHEM in ausreichendem Maße unterstützt wird.
Zustimmung Zustimmung x 6 Informativ Informativ x 1 Liste anzeigen

Offline rob

  • Jr. Member
  • **
  • Beiträge: 69
Ich mach das ähnlich wie Ellert. Und weil die Recherche manchmal schwierig sein kann, interessiert mich ein Produkt nur noch 33%, wenn commandref/ Wiki/ Forum oder div. Suchmaschinen keinen Zusammenhang zw. fhem + Produkt herstellen können.
Fehlende/ schlechte Hersteller-Doku, keine/ wenig techn. Details im Manual etc. führen dann zum K.O. - lieber investiere ich Zeit+Geld in unterstützte Alternativen  ;D

Viele Grüße
rob
eingesetztes Sys: fhem@Raspi3B mit DietPi (Debian Stretch) als Unterbau auf USB-HDD am aktiven Hub | Z-Wave Stick Aeotec AEOEZW090-C | nanoJeeLink | SIGNALduino@433 | SIGNALduino@868 | RFXtrx433e | Denkovi USB-OW-Busmaster | Arduinos, ESP-07er und Sonoff Basics m. config. Firmata/EspEasy

Offline thorschtn

  • Full Member
  • ***
  • Beiträge: 147
Bei meinen jarolift rolladen Steuerungen habe ich als Notbehelf die Tasten der original Fernbedienungen jahrelang über gpio gedrückt, weil es keine implementierung des Protokolls gab. Irgendwann kam dann jemand, der das für nen ESP implementiert hat und jetzt läuft eine Anbindung mit Signalduino und FHEM Modul perfekt. Die jarolift Steuerung war aber vor fhem da. Heutzutage Prüfe ich bereits im Beschaffungsprozess ob eine gute Fhem Anbindung möglich ist.
RPi 3 - FHEM 5.9 - Smartvisu 2.9
MapleCUN, Homematic, 433MHz, AB440, 1-Wire Bewässerung & Pool, Jarolift (Bastelbudenbuben), Signal Messenger, Denon AVR, LG WebOS, AmazonEcho, Jura S90 (ESP8266), Sonoff, Xiaomi Mii Sauger, Worx SO500i