Hallo,

suche eine Blockly-Funktion, um einen Wert (z.B. Pozentwert) linear auf einen anderen Wertebereich zu skalieren und umgekehrt.
Hintergrund ist hier einen Prozentwert einfach auf die Farbtemperatur einer Zigbeeleuchtmittel zu skalieren, da KNX keinen Datentyp Farbtemperatur kennt und der Farbtemperaturbereich ohnehin von Leuchtmittel zu Leuchtmittel differiert.
Bisher habe ich die Skalierfunktion einfach über die "+-*/" Funktion im Mathebereich von Blockly realisiert, was aber ziemlich unübersichtlich ist.
In diesem Zusammenhang wäre es auch sinnvoll, in Blockly den Werte- bzw. Definitionsbereich (Min-Wert und Max-Wert) eines Objektes (hier für den ct-Wert des Zigbeeleuchtmittels) abfragen zu können.
Den Min- und Max-Wert eines Objektes kann man zwar manuell am Objekt einsehen und diese Zahl dann direkt eintragen, was im Zweifelsfall aber fehlerträchtig ist.

Wer hat da eine Idee?

Danke, viele Grüße
Axel

Hallo,

das Problem tritt bei mir auch wie beschrieben auf. Bin gerade durch suchen mit G. eure Beschreibung gestoßen. Scheint tatsächlich ein Bug zu sein.

Gruß Axel

Hi,
gibt es inzwischen Möglichkeiten das Miboxer Gateway WL-Box1 aus dem iobroker anzusprechen. Der MiLight Adapter im iobroker funktioniert ja bekanntlich nicht mit der WL-Box1. Leider findet man auhc die alte Tuya app Version <3.14 nicht mehr, mit der es angeblich gehen soll

Danke, Axel

@Stuebi
Hallo @Stuebi
hier das debug log der shelly-instance. Die shelly Instance ist danach rot, hat also keine Verbindung.

shelly.0	2019-04-13 17:58:18.469	warn	Exception: Error: addMembership EADDRINUSE
shelly.0	2019-04-13 17:58:18.236	info	Starting shelly.0 in version 2.1.9
shelly.0	2019-04-13 17:58:18.213	info	starting. Version 2.1.9 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.15.1

ip addr auf diesem raspi bring dann folgendes:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 1a:30:81:a9:93:37 brd ff:ff:ff:ff:ff:ff
3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN group default
    link/ipip 0.0.0.0 brd 0.0.0.0
4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN group default
    link/sit 0.0.0.0 brd 0.0.0.0
5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether e0:76:d0:2c:84:ff brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 1a:30:81:a9:93:37 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.6/24 brd 192.168.0.255 scope global br0
    inet 169.254.138.51/16 brd 169.254.255.255 scope global br0
    inet6 fe80::1830:81ff:fea9:9337/64 scope link
       valid_lft forever preferred_lft forever

Was mich stuzig macht ist die IP 169.254.138.51 auf der bridge br0. Die habe ich nirgends angelegt. Wenn ich das richtig lese ist Multicast auch an.

Seit dem Anlegen der br0 brauchen winscp und putty aber auch deutlich länger, um sich zu verbinden.

Gruß Axel

Hallo,

die shelly Instance auf meinem iobroker startet nicht mehr und bringt die Fehlermeldung "addMembership EADDRINUSE" sowohl über das log als auch beim manuellen Starten über die Commandozeile.
Habe das gerade gemerkt, weil sich die Lampe am shelly1 nicht mehr über einen KNX-Taster steuern lässt, was ich über ein script realisiert hatte.
Beim Recherchieren im Netz bin ich darauf gestoßen, dass es Probleme bei einer Netzwerk-Bridge geben soll. Da ich hier vor kurzem eine "br0" angelegt habe, und in diese eth0 und wlan0 integriere, um am Server unter raspbian gleich einen WLAN Accesspoint zu haben, könnte da ein Zusammenhang bestehen.
Kann das jemand bestätigen, dass der shelly an einer bridge nicht läuft? Andere Adapter funktionieren ja auch mit Bridge, so dass mir das unverständlich ist, warum gerade der shelly da ein Problem mit der Bridge hat.
Danke für Eure Hilfe, viele Grüße
Axel

Hallo Chefkoch,

auch bei der 1.0.20 habe ich leider weiterhin Probleme meine KNX-Projekt-Datei einzulesen. Habe die 1.0.20 installiert, dann die KNX-Objekte in eine json Datei gesichert. Dann habe ich mal den Zweig für meine KNX-Außenobjekte gelöscht. Beim Einlesen der knx.proj Datei (nur neuere Objekte) kommt dann kurz eine Meldung "Handling devices finished". Der rollende Wartebalken läuft aber weiter bis in alle Ewigkeit, ich muss dann wieder mit Speichern und schließen abbrechen.
Der erhoffte Erstellen des Zweiges mit den Außenobjekten hat nicht geklappt. Habe diese dann aus der json-Datei wiederhergestellt.
Alle anderen Teile von iobroker sind soweit aktuell, habe vorher alle Updates eingespielt. Kann ich eventuell dir die proj-Datei mal zukommen lassen, damit du das Einlesen testen kannst?

Viele Grüße
Axel

Hallo flkontakt,

danke für Deine Antwort

Bei der HUE Bridge hatte ich das Problem, dass die HUE Instanz keine Rückmeldung brachte ob die Lampe an oder aus ist, wenn man sie z.B. mit der Fernbedienung schaltet, während das in der HUE App angezeigt wurde.

Habe es gestern mit der tradfri Bridge aber noch hinbekommen. Habe irgendwann nochmal beide Q-Lampen in meinem Bad zurückgesetzt und die tradfri Bridge auch, dann ging das auch mit dem Einbinden. Aber man muss wohl zunächst erst mal eine tradfri Fernbedienung an der zurückgesetzten Bridge anmelden, sonst kommt man gar nicht weiter.

Problem ist halt auch, dass alle Hersteller die Art und Weise wie die Zigbee Verbindung hergestellt wird anders lösen. Man muss dann schauen, wie man die Beschreibung im tradfri für deren Fernbedienung auf die Q-Fernbedienung uminterpretiert. Wobei das in der Q Anleitung natürlich auch beschrieben ist.

Zur Zeit kämpfe ich noch damit die Verbindung zwischen KNX und tradfri mittels blockly herzustellen. Bei der Rückgabe des Status scheint in meinem Script noch der Wurm drin zu sein.

Danke, viele Grüße

Axel

Hallo,

habe einige Q-Lampen von Paul Neuhaus.

Wer hat die am iobroker zum laufen bekommen? Welches Gateway (Hardware) nehmt ihr. USB-Stick scheidet hier aber aus, da iobroker nicht in der Nähe der Q-Lampen.

Habe hier sowohl mit tradfi als auch mit dem hue Gateway Probleme die Lampen einzubinden.

Danke, Gruß Axel

Hallo Chefkoch,

habe gerade Deine Version 1.0.19 getestet. Zunächst sicherheitshalber alle KNX-Objekte in json gesichert.

Dann alle KNX Objekte gelöscht.

Meine aktuelle KNX Projektdatei eingelesen. Während des Einlesens kommt kurz mal ein Logscreen auf den Bildschirm, wo einige meiner Datenpunkte auftauchen. Der verschwindet aber genauso schnell wie er kam auch wieder.

Das Einlesen kommt wie auch schon mit der 1.0.17 nicht zum Abschluss. Die Version 1.0.18 hatte ich nicht probiert.

Wie lange muss man denn da ca. warten pro Objekt?

Bei den Objekten hatte er nach einer Weile nur den info-Zweig angelegt aber keine KNX-Objekte. Hatte parallel mit einem anderen Browser geschaut, ob da was passiert.

Habe das Einlesen also nach ca. 10 Minuten abgebrochen und daher nun erst mal die Objekte aus der json-Datei wiederhergestellt.

Nach dem Einspielen der json-Datei hatte ich auf die EA Schaltobjekte zunächst keine Schreibrechte aus dem iobroker admin heraus mehr, während die Statusobjekte den Aktuellen Wert anzeigten. Das hat sich aber inzwischen gegeben, war offenbar nur eine Frage der Zeit (ca. 1/2 Stunde).

Werde mal die nächsten Tage nochmal meine projekt-Datei versuchen einzuspielen, die ich dir Ende August letzten Jahres zum Testen herübergegeben hatte.

Meine ETS Version ist hier derzeit die 5.6.6 (Build 1190). Die ist aktuell. IoBroker läuft unter raspbian auf dem bananapi m3 wie bisher.

Einlesen neue KNX-Objekte derzeit nach wie vor nur via Version 0.86 möglich.

Danke, viele Grüße

Axel

Hallo,

habe nochmal mit meinen Einstellungen herumprobiert.

Mit der aktuellen 1.0.17 werden keine Objekte mit meiner knxproj erzeugt.

Hatte darum mal eine alte Fassung der knxproj genommen die letzte, die ich noch mit ets4 erstellt hatte.

Auch hier kam das Einlesen nicht zum Ende.

Daraufhin habe ich iobroker.knx version 1.0.15 installiert.

Alte Fassung des knxproj von ets4 erneut eingelesen. Da wird er dann mit der 1.0.15 auch fertig und erzeugt die Objekte.

Daraufhin meine aktuelle knxproj eingelesen. Da habe ich das Einlesen dann abgebrochen, weil er nicht zum Ende kommt.

Gleichzeitig habe ich das Gefühl, dass er nun ständig erneut Objekte anlegt, als wenn die Version 1.0.15 nun all die Objekte abarbeitet, die unter 1.0.17 nicht erfolgreich angelegt worden sind. Vermutlich existieren da entsprechende temporäre Dateien, die nun abgearbeitet werden.

Habe das aber hier erst mal abgebrochen, weil die Rollläden jetzt am Abend dadurch ständig hochgehen und will das morgen nochmal testen.

Jedenfalls scheint die 1.0.17 unter bestimmten Bedingungen tatsächlich ein Problem mit dem Erstellen der Objekte zu haben.

Ich bleibe jetzt erst mal bei der 1.0.15.

Viele Grüße

Axel