doof gefragt: Beste Unterstützung in FHEM: HUE oder OSRAM oder Tradfri oder ...?

Begonnen von Pfriemler, 28 November 2018, 13:54:17

Vorheriges Thema - Nächstes Thema

Pfriemler

Leuts, ich würd Euch sogar küssen wenn Ihr drauf stündet. Das nenne ich doch mal einen Input!

Einhundertachtzig Steine für das Phoscon-Interface? Das ist m.a.S.g.W. ein Raspi mit Modul, fertig zusammengebaut mit Gehäuse und Netzteil. Aber wenn das auch nebenbei auf dem Raspi läuft? Prinzipiell ist das ja eine wunderbare Sache, und die aktuell 40 Euro für den USB-Stick sind, neben der von gloob verlinkten Anleitung, ja nun wirklich gar kein Aufwand. Das kommt also mit auf die Liste.
Spannender wäre, den Stick nebst Software auf einer anderen Linuxmaschine im Netz laufen zu lassen (etwa meinem NAS, was wirklich dauerhaft läuft).

Habe ich das eigentlich richtig verstanden, dass man HUE-Lampen und kompatible auch direkt verknüpfen kann (muss offenbar danach wieder mit der Bridge verbunden werden) und dann beides geht, also auch ein "Notprogramm" via Fernbedienung, wenn die Bridge down ist?

Zitat von: gloob am 28 November 2018, 14:22:25
Es sollte eher heißen: HUE und OSRAM und Tradfri und ...
Natürlich will ich bedarfsweise alle diese Geräte nutzen. Aber bei der Frage nach dem Gateway ist doch das oder angebrachter.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

CoolTux

Zitat von: Pfriemler am 28 November 2018, 19:27:20
Leuts, ich würd Euch sogar küssen wenn Ihr drauf stündet. Das nenne ich doch mal einen Input!

Einhundertachtzig Steine für das Phoscon-Interface? Das ist m.a.S.g.W. ein Raspi mit Modul, fertig zusammengebaut mit Gehäuse und Netzteil. Aber wenn das auch nebenbei auf dem Raspi läuft? Prinzipiell ist das ja eine wunderbare Sache, und die aktuell 40 Euro für den USB-Stick sind, neben der von gloob verlinkten Anleitung, ja nun wirklich gar kein Aufwand. Das kommt also mit auf die Liste.
Spannender wäre, den Stick nebst Software auf einer anderen Linuxmaschine im Netz laufen zu lassen (etwa meinem NAS, was wirklich dauerhaft läuft).

Habe ich das eigentlich richtig verstanden, dass man HUE-Lampen und kompatible auch direkt verknüpfen kann (muss offenbar danach wieder mit der Bridge verbunden werden) und dann beides geht, also auch ein "Notprogramm" via Fernbedienung, wenn die Bridge down ist?

Lass uns das mal zusammen testen. Ich will mir das Aufsteckmodul holen und auf meinem zweiten FHEM Server aufsetzen. Zusammen mit der Software sollte das hoffentlich gut gehen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Pfriemler

Zitat von: CoolTux am 28 November 2018, 19:40:40
Lass uns das mal zusammen testen. Ich will mir das Aufsteckmodul holen und auf meinem zweiten FHEM Server aufsetzen. Zusammen mit der Software sollte das hoffentlich gut gehen.
Ich dächte, dafür gibt es schon Erfahrungswerte. Ist jetzt aber nicht wirklich dramatisch.
Mir war nicht erst ganz klar, ob deCONZ das Gateway auch für die Phoscon-App ist. Scheint aber doch so.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

DS_Starter

ZitatAnstatt des Phoscon Gateways würde ich einen Raspberry Pi + Raspbee oder Conbee kaufen und die Software selbst installieren. Ist deutlich billiger und nicht wirklich schwer.

Danke für den Hinweis :)

Jetzt hatte ich mir den Conbee angeschaut. Den sollte ich eigentlich an meinen NUC auf dem FHEM läuft direkt anstecken und entsprechend einbinden können.
Na mal schauen ... auf jedenfall interessant und vor allem integrativ.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Pfriemler

Zitat von: DS_Starter am 28 November 2018, 19:48:31
... Conbee ... sollte ich eigentlich an meinen NUC auf dem FHEM läuft direkt anstecken und entsprechend einbinden können.
Logisch. Auf ein Gateway mehr oder weniger kommt es jetzt auch nicht mehr an  ;D
EnOcean, Rademacher, 2 CULs, ein Signalduino, Bluetooth, Jeelink - und für den Conbee brauche ich einen weitern USB-Hub...  :o
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

sinus61

Zitat von: Pfriemler am 28 November 2018, 19:27:20
Habe ich das eigentlich richtig verstanden, dass man HUE-Lampen und kompatible auch direkt verknüpfen kann (muss offenbar danach wieder mit der Bridge verbunden werden) und dann beides geht, also auch ein "Notprogramm" via Fernbedienung, wenn die Bridge down ist?

Wenn du Hue/Ikea Lampen z.B. mit einem Ikea Taster über Phoscon einrichtest funktioniert das schalten hinterher auch wenn der Raspbee und Fhem nicht läuft.

jsChris

Hi,

ich liebäugle schon länger mit dem ConBee und hab in diesem Thread noch mal eine ganze Menge Anregungen bekommen. Vielen Dank.

Was mir jedoch immer noch nicht ganz klar ist, ist das Thema "Firmwareupdate".

Wenn ich zb. ein Osram Leuchtmittel anlerne, dann ist es häufig so, dass für das Leuchtmittel ein Firmwareupdate ansteht. Bei Ikea eigentlich immer.

1. Ich kann ja nicht mit dem ConBee Firmwareupdates von nicht dresden elektronik Hardware durchführen oder geht das doch?

2. Wie beurteilt ihr denn überhaupt die Wichtigkeit der Updates? So ein Leuchtmittel läuft ja, wenn es mal läuft, aber hier gibt es auch hin und wieder mal Sicherheitsupdates oder eventuell neue Funktionen, ZigBee Anpassungen... Bzw. wie löst ihr das?

Bei Ikea ist es so, dass die erst ab einer bestimmten Firmware Version Hue Kompatibel waren (sind - gibt aber vielleicht die Alten auch nicht mehr...).
Hieße das nicht, ich bräuchte auf jeden Fall noch das Original Gateway, um erst dort anzulernen, zu updaten, ablernen, dann bei Phoscon wieder anlernen? Oder beurteile ich das zu falsch? Im letzten Jahr habe ich mich nicht einmal mit dem Osram Gateway via App verbunden und dem Gateway sowieso verboten nach Hause zu telefonieren. Erst vor kurzem habe ich mal wieder alle Leuchtmittel auf den aktuellen Stand gebracht, da neue hinzukamen. Wenn es einmal läuft, bin ich da sehr träge :)

Viele Grüße
Chris



justme1968

firmware updates gehen nur mit dem jeweiligen gateway des herstellers.

die updates sind oft wichtig weil die leuchtmittel oft mit älterer firmware ausgeliefert werden und der betrieb an ,fremden' gateways meist nur mit neuerer firmware geht.

im wiki steht unter ZigBee noch etwas mehr dazu. 
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Zitat von: justme1968 am 29 November 2018, 10:44:19
firmware updates gehen nur mit dem jeweiligen gateway des herstellers.

die updates sind oft wichtig weil die leuchtmittel oft mit älterer firmware ausgeliefert werden und der betrieb an ,fremden' gateways meist nur mit neuerer firmware geht.

im wiki steht unter ZigBee noch etwas mehr dazu.
Das wiki ist leider nur so schlau wie seine Ersteller (u.A. ich) - da war nur erst mal auf die Schnelle zusammengeklaubt, was bisher bekannt war - deCONZ ist z.B. erst sehr spät überhaupt auf die Liste gekommen. Vielleicht müßte man doch erst mal ein Baustellenschild aufstellen...

Wenn man z.B. das hier liest:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/23#issuecomment-303816290
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/96
sieht es so aus, dass es durchaus eine Art Standard für OTA zu geben scheint, der von deCONZ unterstützt wird.

Eigentlich müßte es mit den ganzen Infos möglich sein, statt deCONZ oder zigbee2mqtt ein serielles 2-stufiges Modul zu bauen, das dann auch OTA direkt aus FHEM unterstützt - vorausgesetzt, der Hersteller hält sich an gewisse Standards (IKEA muß man wohl umpacken...) und es ist bekannt, wo man die OTAs herbekommt.

Vielleicht mag jemand, der den ConBee oder RasBee nutzt, das im Wiki ggf. klarstellen? Das ist als Trockenübung alles nur bedingt nachvollziehbar...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

ja. der ota update ist im standard mit drin. zumindest inzwischen.

aber: selbst wenn ein hersteller das unterstützt und verwendet, was außer bei dresden nicht dokumentiert ist, muss man auch noch an die jeweiligen firmware files kommen. und die lassen sich zumindest bei phillips und osram nicht einfach irgendwo runterladen.

und falls der download nicht geschützt ist und man mit sniffen könnte, bräuchte man dazu auch dir original bridge. dann kann man das update auch gleich so machen.

und wenn es den download gibt muss auch die version von der man updated den standard ota update unterstützen. sonst braucht man zumindest ein mal den hersteller eigenen update.

zusätzlich zum standard weg sind aber sich noch signaturen nötig. ich weiß nicht wie weit der standard das abdeckt und wie weit das jeweilige device ein update akzeptiert das von einem anderen sender mit anderer signatur kommt. selbst wenn das protokoll an sich standardisiert ist.


also alles in allem noch nicht wirklich praktikabel und mit einer ganzen reihe fragezeichen versehen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

jsChris

Danke für die Antworten zum Thema Firmwareupdates. Im Grunde, hatte ich auch nichts anderes erwartet, aber ich dachte, ich hätte vielleicht doch etwas übersehen.

Ich hätte trotzdem Lust / Spass daran, mich auf den ConBee einzulassen, weil einfach immer mehr gute ZigBee Produkte auf den Markt kommen, aber mir ist jetzt auch klar, dass ich auch die entsprechenden original Gateways brauche, zumindest von den großen Herstellern, die ihre updates ausschließlich über den eigenen Gateway zulassen.

Danke
Chris

Beta-User

Da das hier den aktuellen Stand der Einbindung der zigbee-Geschichten ganz gut wiedergibt:

@Pfriemler: Magst du das nach zigbee verschieben?

(Und an einen Moderator: am besten da anpinnen?)

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

binford6000

Zitat von: gloob am 28 November 2018, 14:43:08
Die FHEM Integration läuft über eine HUEBridge:

defmod deCONZ HUEBridge 192.168.1.18
attr deCONZ createGroupReadings 1
...


Die einzelnen Devices werden dann als HUEDevice eingebunden:

defmod HUEDevice1 HUEDevice 1  IODev=deCONZ
attr HUEDevice1 IODev deCONZ
attr HUEDevice1 alias Light 1
attr HUEDevice1 color-icons 2
attr HUEDevice1 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEDevice1 model LST002
attr HUEDevice1 room Homekit,Zigbee
attr HUEDevice1 subType extcolordimmer
attr HUEDevice1 webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb DEFF26:rgb 0000ff:ct 490:ct 380:ct 270:ct 160:toggle:on:off





Und ja es fallen dann alle Bridges weg: Hue Bridge, Xiaomi Bridge, Tradfri Bridge, ...

Hallo Zusammen,

ich habe den Raspbee jetzt auch im Betrieb. Die Bridge ist angelegt und connected. HUEGroup0 (alle Lichter) und eine manuelle HUEGroup1 (Wohnzimmer) wurden automatisch/manuell angelegt. Den virtuellen Lichtsensor des deCONZ konnte ich auch verbinden.

Die Bridge findet nur keine Lampen!  ???

Installiert habe ich
deconz-2.05.50-qt5.deb
mit ebenfalls aktueller Firmware:

Version 2.05.50 / 8.12.2018
Firmware 262F0500


Ich habe testweise mal eine HUE und eine INNR in der HUE-App gelöscht und aus und wieder eingeschaltet.
Die Phoscon App findet allerdings keine Lichter.

Internals:
   DEF        10.3.3.236
   FD         4
   INTERVAL   60
   NAME       deCONZ
   NOTIFYDEV  global
   NR         32
   NTFY_ORDER 50-deCONZ
   PORT       39702
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   host       10.3.3.236
   mac        b8:27:eb:7b:da:9f
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    deCONZ
   name       moebconz
   swversion  2.5.50
   updatestate 0
   websocket  1
   websocketport 443
   zigbeechannel 15
   READINGS:
     2018-12-10 19:53:45   lastError       link button not pressed
     2018-12-10 21:19:58   state           connected
   helper:
     apiversion 69632
     count      0
     last_config_timestamp 1544473198
     offsetUTC  3600
     updatestate 0
Attributes:
   createGroupReadings 1
   httpUtils  1
   key        AE8A3E4057


Muss ich die alte (originale HUE Bridge 1) abschalten? Dachte es können mehrere Bridges gleichzeitig in Betrieb sein, oder?
Für etwas Hilfestellung wäre ich Euch dankbar!

Falls was fehlen sollte liefere ich das gerne nach  ;)
VG Sebastian

rakete123

Soweit ich mich erinnere, muss man die HUE Devices sehr nah an den Raspbee bringen für die Inklusion. Und vermutlich schadet es nicht die HUEBridge temporär abzuschalten.
Zwave: ZMEEUZB1 (Fibaro, Aeotec, diverse)
Zigbee: Conbee (HUE, Xiaomi, osram)
Homematic: HM-MOD-RPI-PCB + diverse HM-CC-RT-DN
Sonstiges: Harmony, Android, Netatmo, Jabber (talk2fhem)
https://resize2fs.de