[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

Begonnen von CoolTux, 28 Februar 2019, 09:09:18

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: Beta-User am 25 April 2019, 12:04:30
Sehr cool 8) .

Aber warum sind die vier (antifreeze/comfort/shading/ventilate) zwingend? Braucht man teilweise auch nur dann, wenn man die betr. Funktion nutzt..?

Und noch eine Sache, die ich mal ausprobieren wollte: Eventuell kann man auch gleich ein widget mitgeben, also
ASC_Antifreeze_Pos:selectnumbers,0,1,100,1,lin

(evtl. kann man da gleich einen besseren Startpunkt mitgeben, ist ungetestet...)


Zwingend sind diese Angaben da sie abhängig vom ASC Wert sind. Also 1 oder 2.
Ja man kann das auch anders machen. Aber die Zeit wird knapp. Ich schaue was an Zeit noch übrig ist und entscheide dann.
Jetzt halte ich erstmal alle default Werte in der Commandref fest.
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

eurofinder

@CoolTux:
Ich denke da einige hier auf die neu Version in Kürze umsteigen werden, wäre es ggf. hilfreich, wenn du kurz beschreiben könntest, wie die Anwender die Umstellung auf die neue Version am besten vornehmen, da sich ja doch einige Attribute in der Bezeichnung geändert haben. Wie setze ich in der alten ASC-Version die vorhandenen Attribute/Device korrekt zurück, um dann für die neue Version keine Altlasten mehr zu haben. Insbesondere das wiki sollte dann auch aktualisiert werden.

Gruß und danke für das tolle Modul
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

JHo

Das wäre super, ja. Wiki kann ich dann gerne übernehmen.
Bitte auch gleich mit erläutern, ob und wie von der Entwickler- zur Stable-Version mit FHEM-Update umgestiegen werden kann. Ich erinnere mich, irgendwo war mal "gar nicht" (ohne das Modul vorher zu deaktivieren und damit alle Einstellungen/Attribute zu verlieren) gelesen zu haben.

Danke!
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

Beta-User

Die Übernahme der Attribute von alt nach neu macht das Modul automatisch, daher gibt es auch keinen Rückweg (bis die stable dann auch die "neuen" Formen hat). Denn den "Rückweg" müßte ja jemand programmieren, was wenig Sinn macht. M.E. gibt es für "etwas Wagemutige" keinen Grund, mit der Umstellung auf die Dev-Version zuzuwarten, das funktioniert soweit erkennbar problemfrei.

Zum Wiki: CoolTux hat die commandref überarbeitet, wer also die Dev-Version nimmt, kann dann auch gleich die Anpassungen im Wiki machen (vorab eine "Baustelle" aufstellen wegen der Umstellung). Das wäre sowieso hilfreich, damit wir eventuell Verständnisprobleme in der cref vor Auslieferung als stable erkennen können und da ggf. noch nacharbeiten...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Wie bereits erwähnt übernimmt das Modul vollautomatisch die Umstellung. Die Commandref mache ich gerade aktuell für die Dev Version.


@Beta-User
Deine 4 angesprochenden Attribute habe ich nun auch abgefakelt.
Es bleibt als einziges nun zu sehen ASC_Pos_Reading
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

Beta-User

Sehr cool!

Wenn wir nicht mehr diesen ganzen Wust an Attributen gleich sichtbar machen MÜSSEN, erübrigt sich m.E. eigentlich auch weitgehend die ganze Diskussion über das Zusammenfassen der Attribut-Inhalte :o . Dann ist es nämlich vom Start weg nicht mehr unübersichtlich, und man kann nach und nach das "zuschalten", was man braucht (und verstanden hat)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Gebe ich Dir Recht. Aktuell habe ich noch ein Problem aber das löse ich bestimmt die nächsten Stunden noch. Was wir bis jetzt zusammen gefasst haben lassen wir aber auf jeden Fall so.
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

Beta-User

Yup, wieder aufdröseln macht keinen großen Sinn.

Ist es angedacht, optional defaults zentral (beim ASC-Device) zu hinterlegen? (eilt definitiv nicht...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Nein ist nicht angedacht. Das macht irgendwie kein Sinn. Dann haste Attribute im ASC welche ja auch beim Rollladen sind. Das ist in meinen Augen nicht Sinnvoll
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

Beta-User

Muß mal noch etwas intensiver drüber brüten.

Gedacht hatte ich z.B. an Dinge wie die Blocking times. Da wäre die Frage, ob es für die Mehrzahl der user, die das überhaupt verändern wollen nicht ausreichend wäre, das nur einmalig und zentral zu setzen.

Oder die Sensoren (da weiß ich grade nicht, welchen Stand wir im Moment im Modul haben, kann sein, dass das teilweise schon so funktioniert): Da gab es z.B. Leute, die diverse Helligkeitssensoren einsetzen wollen, aber häufig reicht einer (oder es sind nur Teile der Rollläden, für die andere Sensoren maßgebend sein sollen).

Ziel sollte halt sein, die Konfiguration einerseits flexibel zu halten (=pro Rollladen), andererseits aber auch einfach an zentrale Vorgaben ranzukommen (defaults aus dem ASC-Device), was es erübrigt, alles "zu verteilen" und damit übersichtich zu bleiben.

Mal schauen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Ich habe nun eine neue Developerversion online gestellt. Wer komplett von vorn an fängt bekommt lediglich 1 ASC_ Attribut nach dem ausrollen in sein Rolllo Device.
Schaut mal bitte wegen der Commandref. Wäre super wenn 2-3 Leute die neue Version testen könnten.

Denkt bitte daran das die Commandref neu erstellt werden muss.

cd /opt/fhem/
/usr/bin/perl contrib/commandref_join.pl



Grüße
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

majestro84

Spiele ich gleich Mal ein und werde berichten falls was schief läuft
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

majestro84

Frage: Sollten die Attribute in den Devices auch bei einer vorhandenen Installation verschwinden? Bei mir sind alle nicht konfigurierten Attribute immer noch da.
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Zitat von: majestro84 am 25 April 2019, 17:49:09
Frage: Sollten die Attribute in den Devices auch bei einer vorhandenen Installation verschwinden? Bei mir sind alle nicht konfigurierten Attribute immer noch da.

Na Gott sei Dank. Sie sollten alle da bleiben da sie ja schon einmal in die Konfig geschrieben wurden. Du solltest also weiterhin viele Attribute im Rollladen haben.
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

majestro84

Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT