Zufallszahl in ein Attribute schreiben?

Begonnen von Typ1er, 19 Mai 2019, 00:43:41

Vorheriges Thema - Nächstes Thema

Typ1er

wie schreibe ich den eine Zufallszahl in ein Attribute?

als Reading:
setreading Rollladen_Bu ASC_Drive_OffsetStart {(int(rand(600)))}

wie mache ich das beim Attribut (mein Beispiel klappt so nicht):
attr Rollladen_Bu ASC_Drive_OffsetStart {(int(rand(600)))}

Wie bekomme ich hier direkt den Wert angezeigt

amenomade

Was willst Du erreichen? Ein Attribut ist einer stabile Wert, der zur Konfiguration gehört. Kann nicht regelmässig kalkuliert werden. Jede Änderung benötigt ein "save" in Fhem.

Mit ASC_Drive_Offset und ASC_shuttersDriveOffset kannst Du zufällige Fahrzeiten einstellen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Typ1er

Das ist mir klar, nur möchte ich gern die Rollladen zufällig fahren, und an der Stelle ist die einzige Möglichkeit einzugreifen und die Zeit auszuwerten.

amenomade

Zitatnur möchte ich gern die Rollladen zufällig fahren,
Mit ASC_Drive_Offset und ASC_shuttersDriveOffset fahren die Rolladen zufällig
https://forum.fhem.de/index.php/topic,99980.msg934255.html#msg934255
Was wäre der Unterschied mit deinem Konstrukt auf ASC_Drive_OffsetStart?

Zitatdie Zeit auszuwerten
Die nächste kalkulierte Fahrzeiten kannst Du im Device nw. lesen.

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Typ1er

#4
Das Offset wird nicht ausgewertet, in den Zeiten steht nur das Sunrise/Sunset drin, das Offset kommt erst hinterher hinzu.

Möchte gern die Zeit bis in die Sekunde auswerten.

ASC_Time_DriveUp (Angezeigte Zeit)+ ASC_Drive_OffsetStart (Verzögerung in Sek.)+ ASC_Drive_Offset (Zufallszahl)=berechnete Fahrzeit


Das mit dem Save ist mir schon klar.

amenomade

Dann musst Du mit irgendeinem notify oder at den Wert selbst regelmässig setzen:

..... at *06:00 {fhem("attr ASCdev ASC_Drive_OffsetStart ".{(int(rand(600)))})}
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Typ1er

Da tritt ein  HASH Fehler auf

2019.05.19 13:25:00 1: PERL WARNING: Odd number of elements in anonymous hash at (eval 62411) line 1.
2019.05.19 13:25:00 3: eval: {fhem("attr Rollladen_Bu ASC_Drive_OffsetStart ".{(int(rand(600)))})}

CoolTux


at *06:00 { CommandAttr(undef,'ASCdev ASC_Drive_OffsetStart ' . int(rand(600)) ) }


So sollte es denke ich gehen. Mich erschließt sich zwar nicht warum, aber ist nicht schlimm.
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

amenomade

@CoolTux: wenn Du dabei bist. Ist das nicht ein Verbesserungsvorschlag? Ein Reading mit der nächsten kalkulierten Fahrzeit inkl Astrozeit, offset und zufall offset (ich weiss aber nicht, wie die Zufallsfunktion aussieht)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

CoolTux

Wenn ich die API in ASC geschrieben habe damit jeder an die Werte direkt ran kommt kann das jeder selber machen. Wir reden hier im normal praktischen Anwendungsfall von einer Sichtbarkeit von einer Minute im Reading. Sprich man sieht wann Sunset ist 20:34 und beim besten offsetStart Fall kommt vielleicht 60s drauf. Es kann also maximal 20:35 dann sein. Das offset als Zufallswert kann man nicht fest einbauen. Pauschal kann man sagen es fährt dann 20:36.

Und wer der Meinung ist das OffsetStart als etwas anderes als eine Entzerrung der Fahrbefehle zu verwenden der muss dann mit der Ahnungslosigkeit leben wann die Dinger fahren.

Aber wie gesagt. Wenn ich die API fertig habe bekommt der User lesend Zugriff auf alle internen Werte.
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

Typ1er

Hallo Cooltux, deine Lösung geht, danke.

Ich wollte keinen Streit zu den Fahrzeiten, dein Reading enthält nur sunrise und sunset, das Offset wird nicht mit einberechnet.
ZitatUnd wer der Meinung ist das OffsetStart als etwas anderes als eine Entzerrung der Fahrbefehle zu verwenden der muss dann mit der Ahnungslosigkeit leben wann die Dinger fahren.
Bei mir wird aus der einen Minute, maximal 10 Minuten (bei 11 Geräten), diese Zeit hätte ich eben gern in einem Reading stehen (zur Anzeige in einer readingsGroup), Ahnungslos will da nicht sein.
Das zufällige runterfahren war schon mehrmals gewünscht, nur die Zeit wertet wohl nicht jeder aus.

Meine Lösung jetzt:
-das ASC_Drive_OffsetStart enthält einen festen Wert mit dem man rechnen kann, diesen wollte ich jetzt flexibel überschreiben
-das ASC_Drive_Offset enthält einen Wert, der erst beim ausführen berechnet wird, wenn ich hier 600 oder 1200 draus mache, weiß keiner wann genau der Rolladen fährt(den lasse ich weg)
-die Zeit berechne ich mir in einem userReadings dann neu

wenn du noch einen anderen Vorschlag hast, gerne raus damit

CoolTux

Hier wird nicht gestritten sondern hoffentlich konstruktiv Diskutiert  ;D

Wieso kommen da 10 min zu Stande? Wie groß ist denn Dein offsetStart. Also der Wert zwischen jedem Rolllo meine ich damit.

1 fährt mit 1s
2 fährt mit 3 Sekunden später wie 1 plus die eine Sekunde von 1. Also 4s.
3 fährt wiederum mit 3 Sekunden zu 2 plus 4 Sekunden von 2 also 7s

Im Grunde ist dann zwischen jeden schaltbefehl genau 3 Sekunden. Ausnahme der allererste. Wie viel Entzerrung brauchst du denn?
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

Typ1er

fahren könnten sie alle gleichseitig, die Position am Ende wird nicht übermittelt, wenn sich die Sendebefehle überschneiden.

-ich habe 4 verschiedene Motoren, und damit 4 unterschiedliche Laufzeiten.
- die 10 Minuten waren meine Lösung in meinem DOIF vorher (somit ist kein Muster zu erkennen, wenn welche fährt), dieses wollte ich beibehalten.

Eine andere Lösung ist man fragt die position am Ende ein zweites mal ab, mit einer Pause dazwischen.

CoolTux

Würde also bedeuten im schlechtesten Fall empfiehlt es sich bei jedem Rolllo eine komplette Hochfahrzeit + 2s Tolleranz zu warten bis der nächste fahren kann. Wie hoch ist deine höchste Hochfahrzeit? Weißt Du das?
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

Typ1er

70 Sekunden bei den Jalousien am Wintergarten
der Rest 20-35 Sekunden, je nachdem ob Tür, oder Fenster

CoolTux

Magst du mal zu Testzwecken alle 40 Sekunden probieren? Also 1. Rolllo 1s
2. Rolllo 1s plus 40s
3. Rolllo 40s plus 40 vom 2. Rolllo
Und so weiter.

Ist aber wirklich ganz schön viel. Wegen Darstellung der Zeit schaue ich mal. Eventuell mit einem Attribut im ASC Device und dadurch Setzen eines weiteren Readings im Rolllo Device.
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

Typ1er

Habe ich eingefügt, werde berichten.

Habe noch einen Fehler gefunden, im Z-Wave Dongle wurde nur ein verbundenes Gerät angezeigt, von diesem war dann nur jeweils eine Verbindung zum rest, hier habe alle Parameter nochmal aktualisiert, somit sind alle Rollladen wieder mit jedem Gerät verbunden.