KNX iOS/macOS Software

[brutella]

Ja, die App ist als Ersatz zur ETS gedacht. Die App wird aus technischen Gründen keine Plugins und DCAs unterstützen. Trotzdem sollte es möglich sein, ein komplettes KNX Projekt damit umzusetzen – mit allem was dazugehört.

[AusMinga]

Danke dir, bei all den Bauverzögerungen hier könnte das Tool vielleicht doch noch direkt zum Einsatz kommen, meinem Verständnis nach würde es auch im Einklang mit der ETS arbeiten? Also falls man eine App / DCA braucht dann exportiert man entsprechend? (Lizenz hatte ich schon mal besorgt) Sehr cool dass sich an der Front mit grossen Schritten etwas tut!

[Rucon]

Hallo,

zuerst eimal; danke für deine Initiative eine Alternative zur ETS und dann unter iOS zu schaffen.

Ohne jetzt den gesamten Forumsbeitrag gelesen zu haben und nach kurzen Test - Import funktioniert bei meinem Projekt. Geht auch Export nach Änderungen in eine KNXproj. Datei? Ich finde dazu im Programm nichts. Dann wäre dies z.B. Austausch eines Aktors eine Einbahnstraße? Das wäre schade.

Mit freundlichen Grüßen
RuCon

[brutella]

Ein Export, welcher von der ETS gelesen werden kann, ist natürlich geplant.

[brutella]

Die ersten Beta-Releases für iPad sind bereits über TestFlight verfügbar.
Falls also jemand nur ein iPad benutzt und keinen Mac, kann sich trotzdem für die Beta registrieren.
https://signup.knxstudio.at:8843

Hier ein kurzes Video, wie das ganze auf dem iPad aussieht. → https://mastodon.world/@brutella/116725863833312232

[johannesbonn]

Hallo brutella,

bedeutet das, dass man aus deiner App vom Mac oder iPad die Geräte auch programmieren kann?

[brutella]

Ja

[brutella]

Das Erstellen der Gruppenkommunikation zwischen Kommunikationsobjekten und Gruppenadressen kann in der ETS recht knifflig sein. Einige KNX Eigenheiten sind besonders für Einsteiger nicht immer verständlich.

Deshalb möchte ich die verschiedenen Einstellmöglichkeiten von Flags und verbundenen Gruppenadressen in meiner App verständlicher darstellen.

Ist das Communication-Flag deaktiviert, wird klar ersichtlich angezeigt, dass keine Kommunikation stattfindet.

Home copy.png

Sind zwei oder mehr Gruppenadressen mit einem Kommunikationsobjekt verbunden,
- wird die erste Gruppenadresse als sendende Gruppenadresse dargestellt
- werden alle Gruppenadressen als schreibende Gruppenadressen angezeigt.

Dadurch soll deutlicher werden, dass ein Kommunikationsobjekt zwar auf mehrere Gruppenadressen schreiben und von diesen empfangen kann, jedoch immer nur an eine einzige Gruppenadresse sendet.

IMG_1796 3.jpg

Ist diese Darstellung verständlich? Habt ihr dazu weitere Ideen oder Verbesserungsvorschläge?

[sewi]

Wenn du die anderen Flags auch wie in der ETS benennst, sollte statt "Gruppenkommunikation" wohl "Kommunikation" dort stehen. Das trifft auch den Kern besser - es geht um die Kommunikation. Objekt kommuniziert, oder kommuniziert nicht. Die zusätzliche Spezifizierung "Gruppen-" ist verwirrend, denn es gibt keine andere Kommunikation.

Stellt sich auch die Frage ob für einen Anfänger "Lesen", "Schreiben" und "Übertragen" eingängig sind. Du hast ja die Möglichkeit die anders zu benennen und dann in Klammer den Flag-Namen anzuführen. Weil "Lesen" ist ja eigentlich ein Auslesen, "Schreiben" schreibt gar nichts auf den Bus, sondern behandelt die Write-Pakete, und "Übertragen" sendet Änderungen auf den Bus. Welche Worte hier besser sind, weiß ich nicht, aber diese Worte sind mMn für einen Anfänger nicht so eingängig. Du kannst z.B. (und das nur als Beispiel - da gibt's sicher bessere) "Senden (Ü)" dort stehen haben oder "Empfangen (S)" / "Beschreibbar (S)".

[brutella]

Wenn du die anderen Flags auch wie in der ETS benennst, sollte statt "Gruppenkommunikation" wohl "Kommunikation" dort stehen. Das trifft auch den Kern besser - es geht um die Kommunikation. Objekt kommuniziert, oder kommuniziert nicht. Die zusätzliche Spezifizierung "Gruppen-" ist verwirrend, denn es gibt keine andere Kommunikation.

Gute Idee. Werd ich so ändern.

Stellt sich auch die Frage ob für einen Anfänger "Lesen", "Schreiben" und "Übertragen" eingängig sind. Du hast ja die Möglichkeit die anders zu benennen und dann in Klammer den Flag-Namen anzuführen. Weil "Lesen" ist ja eigentlich ein Auslesen, "Schreiben" schreibt gar nichts auf den Bus, sondern behandelt die Write-Pakete, und "Übertragen" sendet Änderungen auf den Bus. Welche Worte hier besser sind, weiß ich nicht, aber diese Worte sind mMn für einen Anfänger nicht so eingängig. Du kannst z.B. (und das nur als Beispiel - da gibt's sicher bessere) "Senden (Ü)" dort stehen haben oder "Empfangen (S)" / "Beschreibbar (S)".

Anfangs hatte ich noch Lesbar (statt Lesen) und Beschreibbar (statt Schreiben). Dann müssten konsequenterweise auch Sendet (statt Übertragen), und Aktualisiert schreiben. Dann ist man aber gleich bei ganz anderen Bezeichnungen als die ETS. Weisst nicht ob das nicht zusätzlich verwirrt. 🤔

[sewi]

Anfangs hatte ich noch Lesbar (statt Lesen) und Beschreibbar (statt Schreiben). Dann müssten konsequenterweise auch Sendet (statt Übertragen), und Aktualisiert schreiben. Dann ist man aber gleich bei ganz anderen Bezeichnungen als die ETS. Weisst nicht ob das nicht zusätzlich verwirrt. 🤔

Bei der Kommunikation ist es so, dass es bereits sehr treffend beschreibt, was passiert.
Bei "Lesen" und "Schreiben" kann man sich noch denken "ich kann den Wert lesen" und "ich kann den Wert schreiben", aber bei Übertragen passt's nicht, und Aktualisiert auch nicht. Mit "KO <Aktion>" passt's (du stellst ein ob das KO übertragen werden kann, das KO aktualisiert werden kann, usw.). Aber das ist halt dann schön lang schon.

Wäre auch die Frage, ob man die Software nicht einfach einsteigerfreundlich und professionell machen sollte. Also: die korrekten Bezeichnungen verwenden, damit die Benutzer sie lernen, aber eine gute Erklärung zur Verfügung stellen. Ich persönlich mag ja die Tooltips bei Autodesk Fusion sehr. Da fährst drüber und bekommst richtig genaue Erklärungen. Liest man sich einmal durch und weiß danach mehr. Weiß aber nicht ob das geht oder Sinn macht.
image.png