Our goal is to provide the best automation and tools to short term rental property managers to streamline guest check-in, audit access logs and reduce energy consumption.
All Smartthings oAuth tokens are encrypted and stored in our database using OpenSSL encryption and our database is only accessible on the internal network of the webserver farm, not directly on the internet.
This is our preliminary version which allows the setting and deleting of lock codes, as well as scheduling them. We've also enabled hooks to control other popular devices as well as query status. In the near future we will be moving away from using the smartthings scheduling service (primarily due to your soft limit of 4 schedules per hub) and will just be sending commands for immediate action from our platform.
Our platform goal is simple. We want to bring smart home technology to the short term rental market. Part of our business will be to provide pre-configured locks and hubs to customers who subscribe to our service for a monthly fee.
In order to allow the customer to still have control over their hub and Smartthings account, we very much need to have a published app, otherwise the oAuth handshake becomes a difficult/challenging task to manage for a "self published" app that lives on different users accounts.
While we see our product as providing an essential service to our customers, it will also often be the first interaction people have with smart home technology. We anticipate that they will want to connect their own devices and will be a great "gateway" to purchasing smart equipment for their principal residences as well.
Thanks for your consideration
Mathew Hunter
Co-Founder of Slickspaces
With the addition of the ability for parseDescriptionAsMap to hanle the
return of multiple read attribute responses, we can be a little more
explicit with how we interpret and parse the responses.
This continues an effort to clean up the SmartSense DTHs and move as
much of the logic as possible into the library. This simplifies the DTH
and has the advantage of having only a single location where issues need
to be fixed.
This is because ZLL bulbs do not report or allow for configuration of
reporting of attributes. As a result if we change a value, we have to
manually call a read of that attribute to update our status.
This is a part of: https://smartthings.atlassian.net/browse/DPROT-227
This changes our smartsense DTHs that don't use the ZigBee library for
everything to have larger delays between ZigBee messages. This is to
reduce the network load to try to work around some of the poorer
behaving ZigBee routers we support.
This resolves: https://smartthings.atlassian.net/browse/DPROT-223
With the changes made for
https://smartthings.atlassian.net/browse/DPROT-200 there were a few DTHs
that were using sendEvent to directly send events generated during
parse. However, because using sendEvent didn't result in parse
returning an event AppEngine would send the description up to the cloud
DTH to be handled. In some cases this resulted in multiple events for
the same device trigger.
This resolves: https://smartthings.atlassian.net/browse/DPROT-215
The configureHealthCheck method and therefore the configure method was
returning a boolean which was causing an exception during the initial
join that would prevent the device from showing up to the user.
https://smartthings.atlassian.net/browse/PROB-1428
(1) SYLVANIA Smart BR30 Softw White
(2) SYLVANIA Smart PAR38 Softw White
(3) SYLVANIA Smart Outdoor RGBW Flex
2. Modify deviceJoinName of NAFTA Lightify product, all the lightify product which use ZHA protocol will be named using "SYLVANIA Smart XXXX".
