Hi Ident
Thanks for the feedback. I realise the application still has some way to go and it\'ll improve further the more time I put into it. Trying to add a mixture of new features as well as tighening up the code in areas too as issues are found or we need more error checking or validation etc.
In regards to your suggestions:
(*) Yep I\'ll reverse the keyarm local help text.
(1) Yes already thought of export of logs to but just hadn\'t prioritised it yet as high as some of the other things I\'ve been adding. What I did do though was leave the box open but read-only so people can cut form it and paste into a file if they want to.
(2) Can you remind me how you\'d want the feedback on the home control items as I\'ve not been able to get my wizcomfort working since I moved to CCLX format (a screenshot would be good). I get a base counter is invalid error everytime I try to put in the file settings and save and can never get past this now. My technical challenge is working out the code on updating this tree control on the fly without needing to rebuild the whole tree every time a feedback value changes. I\'d sort of assumed that if people wanted feedback they\'d put the values directly on the floorplan where they are always in view (see the counters and sensor labels I have in my example).
(3) Yep adding a handler to icons on the image to trigger responses is high on my list of things to do next after the other things at the bottom of this message.
(4) Not sure what you mean by status of zones in images; can you elaborate? If you mean having a \"Zone 12 off\" or \"Zone 12 On\" (or some meaningful textual message) then you can do that now by adding 2 labels with that text and setting each
Comfort Type \"Zone\" and
Comfort State OFF and ON respectively. Of course then these can be layered on top of other zone related images on the floorplan so I think we are achieving what you want as you have more control over where the label goes than automatically putting it say in the middle of the image (where I\'d be tempted to do for simplicity).
The priority order for the next few builds (in not any particular order of priority) is support for:
(A) Outputs
(B) SCS/RIO inputs and RIO outputs
© Flags (with settable polling frequency) or what I\'m going to call \"CounterFlags\". Counterflags being where the value of counter is either zero (FALSE) and anything else (TRUE). You can then setup responses to maintain the counters accordingly. Reason I like the idea of counters for this is that they are non-polled.
(D) DO Action (DA) and returning feedback (RA).
(E) DO Response (R!). Including click on floorplan icon. Wonder whether the click should do a fire-and forget response or an equiv DO action which does do. I already have code where the user picks the response name (for clarity) but what the application actually sends are the DA\'s. At least then you may get more back than just the \"OK\" you get with \"R!\".
(F) Time Programmes (new TAB)
(G) Getting rid of the connection tab so it\'s all done from the keypad instead.
What you\'ll notice from my own floorplan is that the only feature on there not working from my original bespoke version is the Day/Night images. Needing functionality to process parameters. Choice of either \"Flags\", \"DA\'s\" or \"CounterFlags\" to solve this one and this is one area that is driving me now. This decision not helped by current feature in comfort firmware that if you test on Nighttime parameter and sunrise and sunset events you get the opposite value of what you expect (as the value not updated until after the event and not on the event as I\'d have expected) so saving this to a counter/flag would need to be reversed until Cytech fix this. DA would thus seem better choice but then I need a way of setting and parsing the RA response coming back in via the UI :?
Keep sending the feedback though as I\'m keen to keep improving the application. As far as I\'m concerned I\'ve just started so loads more to do.
I just wish Cytech could help by coming up with a more secure logon mechanism so that we can use apps like this via the internet without the usercode being possibly interceptable (I did a wireshark trace to see it\'s too exposed as clear text; only took a couple of clicks to show the whole decoded session!!). Don\'t care about the other traffic as this is not critical in my view as its just informational and as any hacker wouldnt be able to send commands anyway without the logon details it would be secure (or as secure as logging on via the telephone that we can do now) in my view. So please please Cytech if you are listening; any ideas? Apart from my suggestion to support use-once keycodes such as SecureID type fobs (which I guess is a big piece of work) what about having an encrypted logon code based around certificates; both Comfigurator could use to set them up transparently in the UI and our apps could use the same certificate to generate the code at our end. Or something like that!!
Julian
) can use.