Just to add - I found the removal of devices was easiest from the web gui rather than on your phone. If you attempt to delete the smart App prior to devices, and those devices are used in other SmartApps it will fail.
My process is:
Delete each Device from the web gui in your things list (so the things not the template_
Delete the Smart App instance
Delete and Re-Add the devices and Smart App from the templates - don\'t forget to publish each one as you go.
This leaves the system in the cleanest possible state and tidies up the environment.
Thanks,
Matt
Hi Paul
Have tested and it loads fine (takes a few moments to start up, but thats to be expected).
As I said earlier, I would highly recommend starting small and building up - I\'m not sure how ST will handle so many things - perhaps cut the number of flags and counters down as you can always add more later without having to start from scratch.
Thanks,
Matt
[user=139]Pgordon[/user] wrote: Quote:mattbrain wrote: Quote:Hi Paul
I have received your configuration files and will try them now; may I ask - have you started the service with the [start] button? Once both files are uploaded it should display a status of Online or Offline depending on whether it is running?
Thanks,
Matt
No, sorry I hadn\'t... uploading the file was the last thing I did this morning before I stole the LAN cable back for my work laptop... I can give that a go later... I think there may a spare port on the switch in my office, in which case I\'ll grab a longer LAN cable from the spares bin & drape it across the office floor... :-)
[user=912]mattbrain[/user] wrote: Quote:Hi Paul
One other comment - I would highly recommend starting small - maybe pick a few flags rather than the very large number you have chosen. To be honest I haven\'t exposed that many to SmartThings and I would like to do some performance and memory testing on the SmartThings hub to see how it handles it.
I\'ll do some testing now from a Pi perspective and let you know if I see any issues.
Thanks,
Matt
Thanks Matt. Point taken.
I\'ll reduce it to just the ones I actually use, which is a lot fewer than the full 255...
I take it I can just re-upload the config file, & overwrite the previous one.
Yup, download, edit and upload - it will overright the existing config with the new one. You can pull down previous versions via the log files which will package all the logs, old configs and system reports into a tar ball.
Thanks,
Matt
OK so I delete the smart app through the IDE and ALL THE Cytech related ST \"things\" each individually through the app?
Then re add the app and do the discovery?
Yes, but hold fire a moment - I think I may have found a problem with your setup. Give me 10 mins to check and I\'ll get back to you.
Hi Paul, David
Apologies...
Please hold fire with continuing - I think there is a small issue introduced with a change made on Sunday night which means the alarm code can\'t find the configuration file. I\'m going to make a small change and send it over to you both.
Please sit tight, i\'ll be back shortly with an update.
Thanks,
Matt
Hi Guys
I\'m sorry, found the issue, which is a minor oversight and a result of making changes late Sunday. The issue was basically when the alarm service was started from the web gui, it was starting with the wrong working directory and couldn\'t find the configuration files.
It wasn\'t apparent during testing as I manually started and restarted the service which instantiated is differently - oh well, never mind.
The quickest way to get this out to you, rather than use the upgrade mechanism which will require the upgrade test to be written and tested, will be to publish a new image. I\'m in the process of uploading it now and when it is available i\'ll publish the link on this forum.
Again, apologies for this issue, and the inconvenience.
Thanks,
Matt
No worries Matt. Kudos for jumping on it so quickly... - don\'t you *have* a day job?!?!
Paul G.
[user=912]mattbrain[/user] wrote: Quote:Hi Eamon, Paul
Thanks for your comments; in answer to Eamon\'s questions:
1. True - the current solution is dependent on a SmartThings hub which acts as an abstraction layer.
2. Yup - I feel your pain, i\'m in the same boat to add support for Philips Hue. I need to get my hands on some test devices.
3. The commercial version has to be a device which can be installed, configured and relied upon by any installer. Given the rapid pace of development of IoT and the incremental nature in which people add things to their house, it also needs to be end user customisable (for example when they buy a new Hue bulb). The current solution has a number if inherent weak links in the chain which we plan to address in hardware and software. As a result of this, the community version which have a subset of the commercial version from a functionality perspective - and if we are to keep pace with the continual innovation in this space we need to find a commercial model which will allow us to fund the ongoing development.
4. The community version can use any UCM which has an ethernet port (UCM/Ethx) - this does therefore mean it is only as reliable as the household network, RPi PSU (and in the case of SmartThings integration) broadband connection and SmartThings cloud services. The commercial version will use a custom UCM as well as the industrial version of the RPi (Compute module). This will allow us to directly connect the RPi to the alarm, power it directly from Comfort (and therefore have redundancy) and introduce a variety of measures to ensure it is robust and self recovering.
5. It\'s a little early to be committing to timelines, but it is fair to say both Cytech and alphaWerks recognise this is an import piece of development for the Comfort ecosystem and has the possibility of opening Comfort to new markets.
A couple of final comments from me - we are currently identifying which device families should be high priority. Whilst SmartThings has demonstrated the value this integration can bring, it is only generally available in limited markets (UK & US) and is still very much a hobbyist solution. I see Philips Hue as an ideal candidate for native support; it is widely adopted, low cost and available in many markets. If there are other obvious device families, please let me know and we can consider adding them to the roadmap.
I also need to explain why some devices may only be available in the commercial version. The cost of development and continued support for some device families make it impossible to support gratis - for example, proper IFTTT integration (rather than via \'maker\') requires both dedicated cloud server(s) and annual fee to integrate - and we need to find a way to fund it. It would be unfair to provide those services for free to users of the community version when it is being paid for by users of the commercial version. Having said all that, I am committed to continue to develop the community version wherever possible and from a purely development perspective, it is easier if they both operate from the same source tree.
Anyway, I hope all that makes sense - and look forward to your feedback,
Thanks,
Matt
Hi Matt,
Thanks for the reply, very helpful as usual, and also trigging lots of other possibilities, this s really excting stuff. I fully understand and appreciate the logic behind the community version versus the commercial version as you have explained it.
You menton IFTTT, which again is something that gets the juices flowing, as if we had IFTTT integration, then the possibilities expand even further, am thinking for example of options around geo-fencing and activation of comfort responses based on that. Other possiblities also such as integrating IFTTT compatible routers where we can start getting comfort to behave based on how is home (what devices are registered on the router etc.)
I took a plunge and purchased a hue hub today, so part of the way there, just need the ST hub now, and rpi :-)