Trigger mit Strings

[Asgothian]

@fir3drag0n warum so kompliziert ? Warum nicht einfach :

Und wenn du nur ganze Vielfache von 10 haben willst:

Nachtrag:

Mit dieser Anpassung bekommst du beim Anstöpseln eine Meldung wie weit der ID3 aktuell geladen ist.
Wenn du alle 10 % über den Ladezustand informiert werden willst würde ich den Folgenden Ansatz nutzen:

[Dr. Bakterius]

@fir3drag0n sagte in Trigger mit Strings:

Wie verhindere ich, dass es bei den 10% stehen bleibt?

Indem du für jeden 10%-Schritt eine eigene Variable nimmst und darauf prüfst. Oder du schreibst in die Variable den gemeldeten Wert rein und prüfst darauf. Also wenn 10% erreicht, dann schreibst du '10' in die Variable. Und du prüft bei 10% ob die Variable kleiner 10 ist, bei 20% ob sie kleiner 20 ist, usw...

[fir3drag0n]

@asgothian das funktioniert jetzt, perfekt!

kann ich noch die Bedingung einbauen, dass er mir immer einen neuen Wert übermittelt (bei > 10 SOC), wenn der Wert mindestens um 5 höher liegt?

[Asgothian]

@fir3drag0n Klar.. du musst nur die Berechnung des "Limits" und des Textes anpassen. Wenn du dir die Formel hinter und

anschaust dann liefern die immer Zahlen im 10-er Raster. Wenn Du ein 5er Raster haben willst sollte es reichen die beiden Zahlen in den Formeln durch 5 zu ersetzen.

A.

[fir3drag0n]

@asgothian aber /10 * 10 ist doch einfach immer nur der Wert?

Zumindest erhalte ich da immer Werte, die nur durch das Update Interval des Adapters bestimmt werden und wie oft da neue Werte übertragen werden.

[Asgothian]

@fir3drag0n

x/10 * 10 wird auch nie berechnet.

Da steht im einen Fall roundup(x/10) * 10, im anderen rounddown(x/10) * 10

Das Updateintervall des Adapters bestimmt die maximale Frequenz mit der du Meldungen bekommen kannst. Wenn du eine Meldung bekommen hast führt das hochstehen der Meldeschwelle dazu das der nächste wert erst gemeldet wird wenn die neue Meldeschwelle überschritten wurde.

A.

[fir3drag0n]

@asgothian ok, verstanden, aber wieso wird die Abfolge dann nicht berechnet, z.B. bei einem SOC von 60 (%), dann rechnet er also nicht (60/10)*10, sondern macht mit "Limit" was?

Und warum erst dividieren und dann wieder mit dem selben Wert multiplizieren?

[Asgothian]

@fir3drag0n

die Funktion roundDown rundet den erhaltenen Wert auf die ganze Zahl näher 0
die Funktion roundUp macht es in die andere Richtung (ganze zahl von 0 weg)

bei 60 lohnt das nicht, aber.. wenn es eine Aktualisierung mit 56 gibt, dann liefert
roundup(56/10) * 10 die Zahl 60, während rounddown(65/10)*10 die Zahl 50 liefert

das ganze funktioniert letztendlich so das erst dann eine Nachricht geschickt wird wenn der aktuell vom Adapter gemeldete Wert das Limit übersteigt.
Ein wert von 60 erzeugt also noch keine Meldung, die Meldung kommt erst wenn 61 gemeldet wird. (oder 60.00000001)
Dann wird durch rounddown(61/10)*10 die Meldung "zu 60% geladen" ausgegeben, und durch roundup(61/10)*10 wird das Limit auf 70 angehoben. Die nächste Meldung kommt also erst wenn 70% überschritten wird

A.

[fir3drag0n]

@asgothian dann funktioniert es in dem Fall aber nicht, weil bei mir auch Werte dazwischen gemeldet wurden

[Asgothian]

@fir3drag0n zeig mal genau das was du zusammen gebaut hast

[fir3drag0n]

@asgothian

[Asgothian]

@fir3drag0n

du hast den Runden Baustein an der falschen Stelle eingehängt.

Anstatt "runde ab (wert / 10) * 10" machst du
"runde ab (wert / 10 * 10)

das gleiche beim aufrunden

Vergleich mal:
Deins:

Meins:

So wie du es gemacht hast liefert es alle 1 % eine Nachricht

A.
Nachtrag: der gleiche Fehler natürlich auf bei der Berechnung des Limit