modul für ein I2C Device auf unterschiedlicher Hardware (two level approach?)

Begonnen von klausw, 07 Januar 2014, 17:25:51

Vorheriges Thema - Nächstes Thema

justme1968

1. der key muss eindeutig sein. wie du das erreichst hängt von deinem modul ab. wenn du dein device mit adressen hast ist die adresse gut. wenn du das device weiter unterteilst kannst du diese unterteilung einfach an den key dran hängen. also als key dann z.b. '<addr>.<pin>' verwenden.

je nach dem wie dein modul ausschaut geht das auch gemischt.

2. vielleicht ist es sinnvoll das modul in zwei teile zu trennen. eins was für alle 16 pins auf einem device zuständig ist und eins das als client dran hängt und dann jeweil für 1 oder mehrere pins zuständig ist. eventuell haben die pins ja auch unterschliedliche aufgaben. eins steuert vielleicht einen rolladen, dann sollte es up und down als kommandos geben, ein anderes vielleicht eine lampe, dann sollte es on und off geben.

für das client device kannst du dir auch mal readingsProxy anschauen. damit kannst du genau einen 'teil' (bei dir eben 1 oder mehrere pins) eines device als eigenständiges device ansprechen und flexibel mit eigenen kommandos und icons und webCmd versorgen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

klausw

Zitat von: justme1968 am 15 Januar 2014, 22:55:36
2. vielleicht ist es sinnvoll das modul in zwei teile zu trennen.
dann würde es ein three level approach werden, I2C-Schnittstellenmodul->I2C-ICModul->Pinmodul
geht das überhaupt?
Zitat von: justme1968 am 15 Januar 2014, 22:55:36
für das client device kannst du dir auch mal readingsProxy anschauen. damit kannst du genau einen 'teil' (bei dir eben 1 oder mehrere pins) eines device als eigenständiges device ansprechen und flexibel mit eigenen kommandos und icons und webCmd versorgen.
Den nutze ich schon für ein anderes Modul. Klappt super. Aber das mit den GPIOs war nur ein Beispiel.
Es könnten stattdessen auch PWM Stufen sein (die nutze ich für meine Vitrinenbeleuchtung) oder RGB Treiber.
Da würde readingsProxy sicher an seine grenzen stoßen.

Grüße
Klaus

gruss
  andre
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

justme1968

ja. das geht auch mit drei stufen. wobei die zweite und dritte stufe aber anders zusammen arbeiten wie die ersten beiden. ich verwende das bei panstamp/swap/rgb modul. die schnittstelle zwischen swap und nachfolgendem modul ist aber selber gebaut.

so lange es set und get und eindeutige readings gibt sollte es mit dem readingsProxy funktionieren.

und selbst wenn nicht ist es vielleicht immer noch einfacher den readingsProxy für die einfachen dinge zu verwenden und wenn es nicht mehr geht ein eigenes modul zu schreiben oder auch den readingsProxy zu erweitern.

erst wenn so viel logik nötig ist das du mehr code schreibst als du durch den readingsProxy einsparst ist ein eigenes modul besser.

aber pwm stufen sollte eigentlich noch gehen und rgb geht auf jeden fall. sogar mit farbigen lampen icons und colorpicker. spiff verwendet das um mit einem readingsProxy und ECMD einen dmx controller für farbige lampen zu steuern.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

klausw

Dein readingsProxy Modul verwende ich ja schon erfolgreich für einfache Schalter.
define netzer1b readingsProxy netzer01:Port_b
attr netzer1b room Netzer
attr netzer1b setFn {($CMD eq "off")?"b 0":"b 1"}
attr netzer1b setList on off
attr netzer1b valueFn {($VALUE == 0)?"off":"on"}

Es Anstelle mehrerer einzelner Module zu verwenden ist verlockend. Aber am PWM/Dimmer bin ich bisher gescheitert.
sobald ich eine setlist mit state:slider,0,1,100 anlege kommt folgende Fehlermeldung:
Unknown argument 40, choose one of on off state:slider,0,1,100 off-for-timer off-till on-till on-for-timer intervals blink

Hast du einen fhem.cfg Auszug zu einem Dimmer für readingsProxy?

Ein weiteres Problem könnte sein, das ich für off -> 0 und für on/bzw 100 den Wert FF zurückliefern muss.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

justme1968

das problem ist das es für state noch keine sonderbehandlung gab.

wenn ein slider für <cmd> mit '<cmd>:slider,min,step,max' definiert wird ruft fhemweb nach dem eingestellen normalerweise 'set <device> <cmd> <value>' auf. wenn <cmd> abder state ist lässt fhem das state weg und ruf nur 'set <device> <value> auf.

das habe ich eben im readingsProxy repariert und es ist ab morgen im update.

du kannst es heute schon mit einem anderen reading/wert anstelle von state testen. also pct/bri oder was auch immer.

das mit 0 für off und FF für on und 100 ist kein problem.genau dafür ist ja die setFn da.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

klausw

Hi Andre,

danke, state funktionert jetzt.

Ich wusste gar nicht, das es auch noch andere slider gibt.

Grüße
Klaus
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280