HS/FS Entwicklungsstop ByteCode und xxAPI

[NilsS]

Aus aktuellem Anlass:

Die Entwicklungsarbeiten an den ByteCode Logiken als auch an der xxAPI sind eingestellt.

Grund dafür sind die ewigen Betteleien nach Quellen/Binaries oder kleinen Anpassungen in der HS Firmware bei Dacom.

Trotz dessen, das die Lizenbedingungen von Linux Kernel und busybox mich eines besseren belehren sollten, scheinen der Fa. Dacom/Gira da wohl andere Lizenzbedingungen vorzuliegen, die ihnen das Recht geben, die Buildroot nicht wie nach GPL gefordert offenzulegen

Ich bin kein Anwalt, hab auch nicht vor dessen Rechtmäßigkeit zu prüfen, aber ich hab auch kein Bock mehr solchen Erweiterungen einer "so alten Plattform" hinterher zu rennen.

Fazit für mich damit.
Logikengine auf Pythonbasis für das WireGate bauen (welches sich Softwaretechnisch ja bereits im Jahr 2010 befindet ) , das die bestehenden HS Logikbausteine konvertiert und im neuen Logikformat
Die neuen Bausteine werden dann aber nicht mehr abwärts kompatibel sein (sprich nicht mehr im HS unterstützt).

Vielleicht gibts ja mal ein UpgradeKit, das die HS Hardware mit Debian und WireGate Repo versieht

Ich werde mein HS sicher im nächsten Jahr verkaufen.

[NilsS]

Bevor die Fragen bzgl. einer Visu auf dem WireGate auftauchen....

Ja auch da wird gebaut zwar nicht von mir aber ich sag nur soviel.... technisch hochwertiger als xxAPI

[swenga]

Moin Nils,

dat ist ja mal ein Kracher! Habe volles Verständnis dazu, da ja Deine Patchworks nicht unerheblich tief in den HS eingegriffen haben und auch vonnöten waren.

Vielleicht sollten wir einen Fred eröffnen, in dem Anforderungen an eine zukünftige Visu/Logikengine gesammelt werden, um die Entwicklung zu kanalisieren.

Ich fang mal an:
Absolutes Muss: WYSIWYG-Visu, hier beisst die Maus keinen Faden ab. Andere Textumbrüche durch Browser-Unterschiede sind ein NOGO!

Ansonsten:
Übernahme von bestehenden Logiken aus dem Experten wäre ein Traum
Trennung von Datenupload und Logikengine, Verzicht auf den kapitalen Neustart bei Änderung von Logiken
Einlesen aller KOs in eine MySQL-Datenbank, daher sofortiger Zugriff auf den aktuellen Stand auch fuer andere Applikationen

mfg

[NilsS]

Übernahme von bestehenden Logiken aus dem Experten wäre ein Traum
Trennung von Datenupload und Logikengine, Verzicht auf den kapitalen Neustart bei Änderung von Logiken
Einlesen aller KOs in eine MySQL-Datenbank, daher sofortiger Zugriff auf den aktuellen Stand auch fuer andere Applikationen

Ich dachte eher an Webbasierte konfiguration da gibts kein upload.
klicken und geht
mit Undo von x Befehlen.

MySQL ist glaube ich nicht nötig. in der Größenordnung sollte XML ausreichend sein.

Resourcenschonender Zugriff für andere Applikationen wäre sicher deutlich besser über Comet + JSON oder Comet + XML

[EPIX]

Na dann warte ich einmal auf eine Weihnachtsumstiegsaktion
HS goes WG
*ganzunverschämtzu Makkischau*

. einer Visu auf dem WireGate auftauchen

und da reden wir von einer Visu a'la Quadclient-Design, oder?

[Bodo]

I werd Naarrrisch

Aus aktuellem Anlass: ...
Ich werde mein HS sicher im nächsten Jahr verkaufen.

Hoi Nils

Meine Unterstützung - und ist sie noch so klein - hast Du.
Das Konzept vom WG ist einfach ideal. Und die Hardwarebasis ebenfalls.
Und sie wäre an die Entwicklung jederzeit anpassbar.

Also kommt jetzt doch der Aprilscherz letzten Jahres.



Edit: es tut mir doch auch leid um die HS Fangemeinde, da geht schon etwas besonderes verloren, wenn ich das richtig einschätze.

[EPIX]

Wg. Unterstützung:
gerne kann ich Euch da ebenfalls helfen, zumindest wenn es um DOKU geht...
Sei nicht böse Nils, aber DAS ist m.E. das Hauptproblem bei deinen bisherigen, genialen Bausteinen und Lösungen:
"Normal-Schoitln" (wie ich) kapieren es einfach nicht....

[Bodo]

Hoi

Ja ich tippe auch gerne was.

[ThorstenGehrig]

Hi Nils,
schade... ich kann den Frust zwar nachvollziehen... bin aber der Meinung das es ein weiter Weg ist eine Visu- und Logikengine zu basteln die der Experten-Entwicklungsumgebung nahe kommt.
Sicher - für einen Softwareentwickler gibt es andere & bessere Möglichkeiten als sich mit dem Experten rumzuschlagen - aber für die viele (zumindest für mich) ist der Experte da schon viel einfacher als sich mit python rumzuschlagen...

Da ich ja auch ein WG habe - werde ich weiterhin von deinen Entwicklungen profitieren - und die entsprechenden Logiken und Aktivitäten auf das WG auslagern...

@EPIX: in meinen Augen ist das WG schon so günstig das eine "HS goes WG" aktion garnicht notwendig ist...

Gruß
Thorsten

[EPIX]

es ist nicht immer der PREIS!!!

Ein HS2WS for Dummies Workshop wäre nicht schlecht...

[Warichet]

Grund dafür sind die ewigen Betteleien nach Quellen/Binaries oder kleinen Anpassungen in der HS Firmware bei Dacom.

The reason for DaCom's position might not be related to license details (although it is a convenient argument)
Maybe it is a simple question of money ? Heck, those guys have to earn their living. I understand they get their share each time a HomeServer is sold, but that might be a bit short.
What about having major upgrades billable ? An idea for a poll, maybe ?
By major upgrades I mean added features (not bug fixes). I would be happy to see 3.0 with full KNX routing (yes, hammering on the same nail) decent web usage statistiques, an "open Ajax" interface, a customizable QC (customer choice for red=On or red=Off)

Ich werde mein HS sicher im nächsten Jahr verkaufen.

Me too, already thought about it.

Isn't it a pitty to have one of the most sophisticated home server, so badly documented, so badly promoted, confined to only german speaking countries. Not convinced ? have a look at the recent posts and see the huge effort it takes to get a HomeServer up an running, when you are not fluent in german.
With such a dumb attitude, it's doomed to fail.

[NilsS]

bin aber der Meinung das es ein weiter Weg ist eine Visu- und Logikengine zu basteln die der Experten-Entwicklungsumgebung nahe kommt.
Sicher - für einen Softwareentwickler gibt es andere & bessere Möglichkeiten als sich mit dem Experten rumzuschlagen - aber für die viele (zumindest für mich) ist der Experte da schon viel einfacher als sich mit python rumzuschlagen...

Ist sicher nicht meine Absicht, webbasiert sollte da sicher reichen, oder

bisschen drag&drop für die Logiken
bisschen dropdown menüs
....mit suchen Feld für die GAs/iKOs (wenn ich sie denn auch im WG mal so nennen darf)

[EIB-TECH]

cool bau ruhig auf Wiregatebasis weiter.

In jede Kundenanlage klopfe eh ein Wireagte zusätzlich rein.

Jeder gewinnt:

- Kunde und ich

wann gibts die ersten Bausteine zum verkaufen ?!

[NilsS]

Dauert noch ein bisschen

nachher kannst du ja dann 2 WireGates verbauen und dir den HS sparen

bzgl. verkaufen ... naja ist halt GPL ...

aber über Hardwarespenden freu ich mich immer

[swenga]

Hallo Nils,

okay, haette an den MySQL vielleicht ein "o.ä." hängen sollen. Allerdings sollte der Zugriff schon objekt- und nicht filebasiert sein, um auch mehrfachen Zugriff etc. zu gewährleisten. Das hast Du allerdings sicher beachtet.

Zum Thema Webinterface: Ich finde die offline-Bearbeitung eigentlich relativ charmant, da man dadurch nicht im Live-System rumfrickelt und auch in der Ferne arbeiten kann. Aber mach mal deine Logiken/Bausteine etc. und dokumentier die Strukturen, dann ein lokales Frontend dazu zu erstellen kann ja dann so subalternen Hilfsknechten wie mir zufallen

Wie hast Du denn vor das Killerargument (zumindest fuer mich) der einheitlichen Visu-Darstellung zu erledigen?

mfg