Visie achter HSTouch (filosofisch :-)

Alles m.b.t. HSTtouch (DUTCH forum)

Moderators: TANE, Ruud

Post Reply
Lennart
Member
Member
Posts: 497
Joined: Sat Jul 22, 2006 10:58 am
Location: Netherlands

Visie achter HSTouch (filosofisch :-)

Post by Lennart »

Ik zit nu een tijdje met HSTouch te experimenteren en er vallen me dan toch wel een paar dingen op. Natuurlijk in de eerste plaats de bugs, maar daar valt wel doorheen te kijken. Wat ik meer bedoel is de gedachte/visie die achter het pakket schuil gaat.

HomeSeer werkt in essentie via het client/server model. HomeSeer is de HA server en je webbrowser is de bijzonder dunne (thin) client waarmee je de server benadert.

We kennen allemaal de beperkingen van browsers en nemen die voor lief (denk aan de niet directe statusupdates als je via een schakelaar een device schakelt => eerst een page refresh nodig). Daarnaast kennen we allemaal de tekortkomingen van de niet erg intuitieve HS webinterface (over WAF gesproken).

Nu we echter HSTouch hebben, zie je dat de client een directere verbinding heeft met de server (bijvoorbeeld: directe status update) en dat die client dus ook "dikker" zou kunnen worden (fat client).

Met andere woorden: HSTouch zou veel meer kunnen doen dan alleen maar basale schermafhandeling met een 1-op-1 relatie naar de HomeSeer devices. Ook application logic zou prima aan de HSTouch zijde kunnen zitten.

Sterker nog: conform het traditionele client/server model zou je juist verwachten dat de application logic veelal aan de HSTouch zijde zou zitten. En dat HomeSeer zelf niet veel meer doet dan devices schakelen, values updaten/uitlezen en events draaien die het algemeen belang dienen (los van een specifieke client).

Dat betekent echter: noodzaak voor volledige scripting mogelijkheden aan de HSTouch zijde. Denk dan bijvoorbeeld aan conditionals (if-then-else statements), loops (for-do, while-do), enz.

Om maar wat te noemen: ik zou graag het tonen van schermen/buttons van bepaalde condities af willen laten hangen (staan bepaalde devices aan? Zo ja, toon het controle scherm/de buttons, anders niet). En ik zou soms een wait aan de HSTouch zijde willen inbouwen (zonder daarvoor een script in HS te moeten aanroepen!). Of lokale variabelen willen gebruiken (zonder een virtual device binnen HS te moeten zetten!). En zo zijn er nog wel meer zaken die generieke scripting aan de client zijde wenselijk maken.

Uiteraard kun je hierin ook te ver gaan (op een gegeven moment kun je misschien beter zelf een client gaan schrijven in C# o.i.d.), maar ik heb het gevoel dat de balans nu wel erg naar de "eenvoud"-zijde in plaats van naar de "functionaliteit"-zijde doorslaat. Conditionals die je bij elkaar kunt klikken op basis van device-status/value (zoals je die min of meer ook in het HS event mechanisme hebt) zijn toch eigenlijk wel het minste dat je zou verwachten.

Mijn vraag: sta ik alleen in het gevoel dat er dus eigenlijk nog wel wat ontbreekt aan de HSTouch functionaliteit? Kijk ik op een verkeerde manier tegen de bedoeling van HSTouch aan? Wat zijn jullie gedachten hierover?

My 2 cents,

Lennart
User avatar
TANE
Forum Moderator
Forum Moderator
Posts: 4806
Joined: Fri Apr 06, 2007 9:46 pm
Location: Netherlands
Contact:

Visie achter HSTouch (filosofisch :-)

Post by TANE »

Ik deel je gedachten.
Een deel van de functie is heel klein beschikbaar met scripting opties.
het is wel jammer dat je in een kleine text veld je script commando's moet opgeven.
HST heeft eindelijk WAF effect kunnen toevoegen..soms wel jammer dat het via een client moet en niet via een browser door gebruik te maken van bv. Flash (zie Maestro).
User avatar
RdP
Advanced Member
Advanced Member
Posts: 989
Joined: Thu May 04, 2006 10:14 am
Location: Netherlands

Visie achter HSTouch (filosofisch :-)

Post by RdP »

Lennart,

Ik denk er net zo over hoor. Ik verwacht dat we op termijn ook wel die functionaliteit kunnen verwachten.
Het is nu af en toe nogal behelpen met HStouch, nog even los van de irritante bugs. Maar ik heb vertrouwen dat het goed komt, het duurt alleen wel langer dan ik gedacht had. Ook is de frequentie van (beta) updates erg laag en zonder veel veranderingen en wordt er maar weinig structureel omgegaan met de ervaringen van de HST gebruikers (zeer slechte communicatie van de HS mensen) Allen RUPP, die eigenlijk helemaal geen HS medewerker is, als altijd zeer responsive....
r_255
Advanced Member
Advanced Member
Posts: 621
Joined: Wed Jun 11, 2008 9:39 pm
Location: Netherlands

Visie achter HSTouch (filosofisch :-)

Post by r_255 »

Het heeft natuurlijk zijn beperkingen, maar als niet programmeur is met hstouch is de drempel toch weer wat lager geworden om een grafische interface te ontwikkelen. Natuurlijk kan en zal de functionaliteit wel uitgebreid worden maar vooralsnog in basis is het voor mij als hsstarter goed werkzaam.


Als ik persoonlijk diep in mijn hart kijk bouw ik het liefst zelf een leuke geanimeerde touchinterface in flash.
Maar dat is voor mij een project als alles werkt en de hardware die nog op mijn lijstje staat geinstalleerd is.

Voor mij geld ook een beetje dat je uiteindelijk alles zelf wel kan doen, maar tijd is hier een factor die een hoop beperkingen opwerpt en als het om een hobby gaat kies je dan voor de manier die je het meeste plezier oplevert.
en wat dat betreft ben ik getouched :D
Bwired
Administrator
Administrator
Posts: 4704
Joined: Sat Mar 25, 2006 1:07 am
Location: Netherlands
Contact:

Visie achter HSTouch (filosofisch :-)

Post by Bwired »

Ik ken HStouch niet, echter denk ik wel dat je zoveel mogelijk vanaf de server moet halen. En dus wel zoveel mogelijk fuctionaleiten op de client beschikbaar stellen maar de application logic centraal regelen. Met de huidige tools zoals Ajax etc is dit volgens mij geen probleem.
User avatar
Rene
Global Moderator
Global Moderator
Posts: 1689
Joined: Wed Oct 08, 2008 3:54 pm
Location: Netherlands

Visie achter HSTouch (filosofisch :-)

Post by Rene »

Ik ben het met Pieter eens. Indien je logica aan de client kant gaat leggen hoe doe je dat dan als je meerdere touchscreens hebt?

Rene.
Digit
Global Moderator
Global Moderator
Posts: 3388
Joined: Sat Mar 25, 2006 10:23 am
Location: Netherlands
Contact:

Visie achter HSTouch (filosofisch :-)

Post by Digit »

Of 0...
Een client zou nmm niet meer mogen zijn dan een visualisatie van wat er zich op de server afspeelt en zich wat dat betreft dus helemaal moeten kunnen redden met wat door laatstgenoemde beschikbaar wordt gesteld. Een client moet vooral niet proberen zelf 'slim' te zijn.
Lennart
Member
Member
Posts: 497
Joined: Sat Jul 22, 2006 10:58 am
Location: Netherlands

Visie achter HSTouch (filosofisch :-)

Post by Lennart »

Ok, voor die zaken die het algemeen belang dienen (denk aan status bijhouden & opslag in een database, devices daadwerkelijk schakelen, events draaien op basis van timers) wil je inderdaad de server het werk laten doen en de client(s) alleen maar de visualiatie. Wat ik echter met application logic bedoelde is eigenlijk de basale application flow (dus niet zozeer de "business rules", maar wel de opeenvolging van schermen). Daarvoor wil je toch wel faciliteiten in de client hebben, lijkt me, aangezien dat client-specifiek is/kan zijn. En juist dat ontbreekt nog voor een groot deel in HSTouch.

Om een concreet voorbeeld te noemen: ik heb een aantal camera's. Die staan niet allemaal altijd aan. Nu wil ik bijvoorbeeld dat een camerascherm alleen geopend kan worden als de betreffende camera aanstaat. En dat als de camera uistaat de camera aangaat en een timer gaat lopen (idealiter ook gevisualiseerd) en na 15 seconden (de opstarttijd) alsnog de camera getoond wordt. Dat soort zaken zijn momenteel helaas niet mogelijk met HSTouch.

Voor de liefhebbers: ik heb dit specifieke probleem deels opgelost door het camerascherm sowieso te tonen en het camerabeeld daarin op te nemen als status tracking image. Als de camera aanstaat (device status is on) wordt als image de camera URL gebruikt. Als de camera uit staat (device status is off) wordt als image een jpg met een testbeeld getoond. En zo klooien we lekker verder :-)

Lennart
Post Reply

Return to “Homeseer HStouch Forum”