Premise So long....

I've decided to move on from Premise and chase some other Automation product(s).
 
Maybe I'll finish my browser version, but not likely. Oddly, I thought when I retired I'd have more time to get it done, but it has fallen down my list of things to do. If anybody wants my nearly done code, I'll be happy to send it.
 
I won't be renewing Premisesystems.com in June 2019. So you'll get a 404 or whatever. Or if you want to have it transferred to you, let me know. Although I paid a few bills for it, I'll transfer gratis. I already let a couple of the other domains expire.
 
Thanks for all of the virtual friendships we've made. I wish you all the best.
 
Chuck
 
 

I left a long time ago. I went with smartthings and haven't looked back. I like smartthings because I can still tinker with it. You had a good run though.

David

Well, this makes me sad.  I knew it was inevitable that the few left would start to leave.  But I'm still sorry to see it happening.
 
Having said that, I have started looking at other stuff myself.  Just haven't had a lot of time.
 
I hope you still pop back and say hi once in a while
 
And, what have you decided to go with?

I have been looking at Smartthings - maybe resurrect the Hub from the garage. I'm also looking at Control4.
 
My biggest challenge, like many of you, has been the lack of drivers. 
 
I need to move beyond the more simpler things like lighting, thermostats, and such. I have a need for security, pool controls, shading, and so on. Smartthings looks like it will be good for some of those things, but its the 'heavy duty' stuff that I need to reliably monitor and control from afar.
 
Smartthings appears to address some of the more simple things. I don't see swapping out my Lutron RA2 system to become compatible with Smartthings (the reason it is in the garage is that I couldn't use Smartthings with ETCs ZWave Premise  driver - I would have had to deprogram each switch, then reprogram for ST, then add Premise in after. No thanks).
 
From the choices I am making while am either installing or upgrading the heavy duty devices, C4 seems to provide the support.
 
But I am still investigating...

Hey there Chuck!
 
Sadly, all good things come to an end.  Nevertheless, I feel fortunate that Premise allowed us to meet and exchange our ideas and handiwork. I hope we can stay in touch and continue to share our adventures in Home Automation.
 
 
FWIW, I have three home automation systems running concurrently.
 

• Premise (on a mini PC; Windows 10)
• openHAB (on a Raspberry Pi; Raspbian)
• Home Assistant (on an old netbook; Ubuntu)

 
All three communicate with one another via MQTT. I can control devices within Premise via the UIs supplied by:

• Home Assistant
• openHAB
• Home Remote (not an HA system, just a front-end app).

All this is possible through the use of MQTT. I used Node-Red and created SyseventBroker in order to provide Premise with the ability to communicate via MQTT.
 
 
Initially I used Home Remote, which supports MQTT, to create a UI. However, it involved a fair amount of work and you'd have to adapt it to the screen-size of the intended display device. I decided to investigate openHAB's ability to serve as a frontend for Premise. You still have to define the UI but it's easier and adapts to various screen-sizes. In addition, I wanted to learn if it could become a potential replacement for Premise.
 
openHAB's UI runs in a browser or in openHAB's iOS and Android apps. I liked the result and used it for a few months. During this time, I continued to learn about openHAB and, although there's a lot to like and it's very powerful, I ultimately decided it was not for me.
 
Whereas Premise defines a home with 'real world' objects (Garage Door, Window Sensor, Security System, Sconces, Thermostat, etc) openHAB uses simpler widgets like Contact, Dimmer, Switch, Number, etc. There's no concept of a thermostat, just a collection of Number and Switch "Items" that, taken together, form a thermostat. After using Premise for 10+ years, it's hard for me to take a step backwards and think like that. In addition , its "Rules DSL" (Design Specific Language), for creating Home Automation logic, is considerably less approachable (and legible) than Premise's VBScript. I really wanted to like openHAB but conceded that I would never enjoy translating all my existing HA logic into openHAB's (comparatively onerous) Rules DSL.
 
I moved on to Home Assistant, which has attracted a sizeable following. First, unlike openHAB biannual releases, its development cycle moves at breakneck speed; a new release appears every two weeks. That's great if you desire new functionality but it often means a slew of 'breaking changes' (some by design and others, not so much). You really have to read the release notes carefully before committing to an upgrade. Otherwise you might be looking at an evening or three of answering "Why does this no longer work?!?". Having said that, there's a lot to like about Home Assistant. It's not as sophisticated as Premise, some things are absurdly hard to do compared to Premise, but then in many others ways it just shines and makes HA life easy (plus its rapid development cycle continues to correct/improve/expand it).
 
Home Assistant provides a more sophisticated collection of home devices such as binary_sensor (on/off/open/closed devices), sensor (temperature, humidity, speed, etc), light (state/brightness/color), cover (a.k.a. blinds/retractable awnings/garage doors), climate (a.k.a. thermostat), lock, etc. What it lacks is the concept of areas (it's on the founder's to-do list). Like Premise's Automation Browser, Home Assistant's "Frontend" generates a UI automatically based on the devices you've defined. The result is a fairly clean and attractive web-based UI that adapts itself to screen-size. All state-changes are automatically logged in a database and the UI can display each device's operating history. They're currently developing an entirely new UI framework called Lovelace. It's faster than Frontend and provides for a more sophisticated and flexible UI (arguably more attractive as well). It can't be auto-generated (yet) based on the defined devices.
 
 
I should mention one thing that both openHAB and Home Assistant do that is alien to a Premise user. If you add a new device or create some new logic, you have to restart the application (or portions of it). openHAB does this transparently because it monitors its configuration files and if it detects they've changed it will restart itself (nevertheless, it's still a complete 'start all over' cycle). Home Assistant must be manually restarted but you should first run a 'Config Check' so that it validates your changes before using them. If it contains an error and you restart the application it may fail and not return to life (then you go hunting through the log file looking for the offending entry). You can change most anything and everything in Premise without having to restart it so this 'must restart' behavior feels nothing short of awkward and primitive. In addition, Premise starts blazingly fast compared to these two.
 
 
Currently, I'm deeply immersed in Home Assistant. There are some things that are just jaw-droppingly easy to achieve (adding comprehensive HomeKit support was a matter of adding a few lines to the configuration file). Having said that, there's a preponderance of things that caused me 'face-palm moments' because I know how trivial it would be to do in Premise (date math in Home Assistant is fugly). In addition, most everything is defined using YAML including automation logic. I don't mind it for defining devices but it's, to put it politely, an 'acquired taste' for creating logic.
 
I have three important devices in my home that don't make it easy for me to shift from Premise to Home Assistant because it doesn't support them:

• HAI Omnistat/2 thermostat
• UPB lighting
• ELK M1

The lack of support for UPB is a major roadblock for me. The switches works well in my home and I have no desire to part with hundreds of dollars to replace them for another technology (just to use another HA software). An ELK M1 driver was recently released for Home Assistant (over a year of development time) so that's encouraging (still stamping out bugs). However, there's no sign any of the 'cool kids' today are using HAI thermostats so a driver for my Omnistat/2 will probably never materialize.
 
Overall, my desire to switch to another HA platform has diminished since the availability of MQTT. I now use Home Assistant as a 'Premise enhancer'. It provides a nice UI and a bajillion drivers for new devices and technologies that, through MQTT, I can continue to exploit via Premise. Here's what I mean. My wife uses an iPhone and she can now ask Siri to:

• Change the thermostat's target temperature.
• Set a light brighter.
• Close the garage door.
• Inquire about the status of the security system.
• etc

The responsiveness is excellent despite the lengthy chain involved in making this magic happen:

• Speak to iPhone: "Hey Siri, turn on the kitchen light."
• Voice is converted to a HomeKit command (probably via Apple's cloud servers).
• Command drives HomeKit app on the iPhone.
• HomeKit app knows the kitchen light is connected to 'Home Assistant Bridge'.
• HomeKit app tells the Bridge to activate the kitchen light.
• Siri responds "Okay!"
• Home Assistant turns on 'light.kitchen'.
• Home Assistant has 'light.kitchen' defined as an MQTT Light, so it publishes the 'turn on' command to the local MQTT Broker.
• MQTT Broker receives it and re-publishes it to all its subscribers, namely a 'flow' in Node-Red.
• The Node-Red flow passes the topics along to Premise's SyseventBroker.
• SyseventBroker converts it into a command to turn on the kitchen light.
• Kitchen light is a UPB dimmer so the command is transmitted to the light via the UPB transceiver.
• Kitchen light turns on.

 
All this happens in about one second (i.e. it feels instantaneous). Basically, I now have HomeKit functionality for all my devices in Premise, thanks to Home Assistant and MQTT (which glues them together).

I like Home Assistant too. I am in the process of connecting my SmartThings hub to Home Assistant using MQTT. I create the logic with WebCore on my SmartThings hub, it is human readable and very easy to setup. I tried openHAB and had it working with my wifi thermostats, but the rapid development of Home Assistant is second to none.

123, maybe you can give a MQTT tutorial!
If I'm tracking correctly, It sounds a lot of what I was using javascript/jquery to do - 'instant' communication between the objects and the UI.
 
I am surprised to hear the issues with rightsizing for screen size. I have that taken care of...
 
There were two areas where I started getting bogged down. 1) I heavily modified your MB module. So I started going back to put back in the 'simple' case logic 2) this is what really has been driving me insane - I created scenes so they could be at the top level (i.e. home page) in addition to the level specific (custombutton). I like being able to have "scene a" everywhere, not just specific to location)
What I found when the page first loads, the scene event(s) load/s correctly. But moving between pages, it requires a refresh to reload the event.
 
That's what really started my reevaluation - so if anybody has an idea....

w84no1 said:

I like Home Assistant too. I am in the process of connecting my SmartThings hub to Home Assistant using MQTT. I create the logic with WebCore on my SmartThings hub, it is human readable and very easy to setup. I tried openHAB and had it working with my wifi thermostats, but the rapid development of Home Assistant is second to none.

Click to expand...

I'm hoping Ellery has the time to join the discussion. The last time we spoke he was using SmartThings with Premise via the SmartThings-MQTT Bridge and SyseventBroker. He shared a few screenshots of the SmartThings app controlling via devices in his Premise home.
 
 

chucklyons said:

123, maybe you can give a MQTT tutorial!
If I'm tracking correctly, It sounds a lot of what I was using javascript/jquery to do - 'instant' communication between the objects and the UI.
 
I am surprised to hear the issues with rightsizing for screen size. I have that taken care of...

Click to expand...

Here's a clear and simple overview of MQTT: https://youtu.be/EIxdz-2rhLs
This is a slicker production: https://youtu.be/NjKK5ab0-Kk
 
As for the right-sizing, that only applied to Home Remote not Home Assistant or openHAB. In Home Remote, you begin designed the UI by first selecting a canvas size and then placing your widgets on it. Obviously you pick the canvas size based on the intended device's screen-size/resolution. If you create a UI for a phone then display it on a tablet, the widgets might not be aligned the way you intended. Home Assistant and openHAB use a different approach where the canvas size is not pre-determined and the widgets adapt to the device's available screen real-estate.

I have seen some HA stuff relating to the Elk M1 panel. 
 
Been tinkering with Home Assistant and impressed with it.  I have HA running on it's own computer now along with Node Red.
 
A week or so ago requested the addition of two new topics under the Market place section of the forum.
 
One would be for OpenHAB and the other for Home Assistant. 

MQTT - pub/sub. We've used that for some time in my past life (we've = my team). Value is easily seen - with MQTT, I particularly like the LWT notion.
I'm more interested in how it is implemented within Premise. And how much more administrative overhead there is.
With two instances of Premise currently running - (Windows 10 and Premise x 2), it can suck up a bit of time. Especially when Windows 10 wants to be upgraded. Does this add a lot more admin work after initial setup?

Chuck, here are a few samples of the UIs I've created in openHAB and Home Assistant. The screenshots are from both systems rendering the current state of devices controlled by Premise (at the same moment in time). Ideally I should've taken screenshots from my phone but that's a bit of a hassle for me so these images are from my browser (set narrow to simulate a phone's screen).
 
This first one is from openHAB using its Basic UI. You define it with a text file (called a "sitemap"). openHAB offers a slicker UI called HABpanel but I've only scratched its surface and don't have anything interesting to share.
 
Notice it indicates 2 lights on the first floor are on (Kitchen and Sink), the HVAC system is actively heating, and the security system indicates one item, the Laundry Door Lock, is not secured.
 
 
 
 

This one is from Home Assistant using its Frontend UI. It's automatically generated based on the available entities (just like Automation Browser does with available home objects). Home Assistant also offers a slicker UI called Lovelace but, again, I've only scratched its surface so nothing worthwhile to share.
 
 
Notice it also indicates 2 lights are on in the house, the HVAC system is actively heating, and the security system shows one item, the Laundry Door Lock, is not secured.   
 
In this UI, I chose to only show the security items that are NOT secured (if the item is secured then its hidden). You can do the same thing (conditionally control a widget's visibility) in openHAB's Basic UI.    
 
 
You may have also noticed that Home Assistant records the history of an entity's state-changes and, by default, displays a history chart in the Frontend UI. To be fair, there are ways to do this in openHAB but there's no free ride; you have to manually setup the history recording and add code to the UI to render the charts. 
 
 
FWIW, those red circles at the top are called badges and are typically used to present the status of a sensor (like a door sensor or temperature sensor).

@123 have you tried my UPB driver for HASS? It works 95%. It's in the hass forums.
 
I think HASS is amazing but even though it supports thousands of devices and vendors, it still doesn't support many of the premier brands and products. It's very much an IoT/DiY controller as nobody is adding the RA2/HAI/RTI/etc integration code to it yet. (Though it just got support for ELK a few weeks ago which I thought was a major milestone)
 
I was on CQC and jumped to HASS. Comparatively I think HASS is leaps and bounds better than CQC but I did have to write a bunch of custom hacks to get my system working. My Python isn't strong enough to get official code into Home Assistant as the programming style is way over my head.
 
.

bbrendon said:

bbrendon, on 20 Nov 2018 - 01:56, said:
@123 have you tried my UPB driver for HASS? It works 95%. It's in the hass forums.

Click to expand...

If you mean this one then, no, I have not.
https://community.home-assistant.io/t/upb-lighting-controls-one-way/11690
https://github.com/bbrendon/HASS/blob/master/custom_components/light/README.md
 

Limitations
No access to links
Not two-way. i.e. You can control the lights from HASS but changes in the physical world don't appear in HASS.
Not fully python native - requires upb-cli node application.

Click to expand...

Respectfully, its lack of support for two-way communication, and links, are drawbacks for me. From Home Assistant, I can access Premise's UPB driver via MQTT so I get two-way communications (all lights are modelled with the MQTT Light component).

Yes, this means running both Premise and Home Assistant. I've come to the realization that it's not much different from how Home Assistant users run Node-Red for their automation logic. Currently, Premise continues to run both logic and all drivers. I use Home Assistant, via MQTT, to provide a UI and for integration with HomeKit.

Ideally, there ought to be a native Home Assistant UPB driver with full functionality. However, I agree with you that developing a new platform requires a solid background in python programming and an understanding of a component's classes and overall structure. In addition, you have to write the underlying UPB interface (effectively something like upb-cli) and post it to pypi.org. So far, I've managed to modify the MQTT HVAC component to suit my needs but contributing it to GitHub, for inclusion into the main program, is still a bridge too far for me.

Over the last 15 years, I have lurked on this forum as a Premise user.  When I built my home in 2003, I selected my home automation systems based on the list of supported Premise devices: Lutron Homeworks for lighting and Caddx NX-8e for sensors and alarm.  The Lutron HomeWorks HWI system finally had to be upgraded to HomeWorks QS and after that upgrade, the Lutron interface in Premise no longer worked.  I found Smartthings to be quite capable for many home IoT's and enjoyed learning the API and a little groovy etc.  I even figured out how to interface the NX-8e to Smartthings.  However, Smartthings does not support Lutron QS or Radio RA and probably never will since Lutron reserves the implementation of those system to its suppliers.
 
During one of my occasional visits to the Premise forum I saw 123's notes on MQTT and HA.  So, I started investigating and found that with Home Assistant, I could replicate all the integrations that I had become accustomed to with Premise.  This was accomplished when I discovered how to add the Lutron QS interface to Home Assistant (it also works with Radio RA) and then how to link Smartthings with MQTT.  I dropped Premise with sadness and a flick of a switch and moved to Home Assistant as the primary integration system, user interface, and automation interface; and, Smartthings as the easy-to-use hub for attaching inexpensive Z-Wave devices, ZigBee sensors, a bridge to Caddx NX-8e, and other devices.
 
Running Home Assistant on a Pi, I can now enjoy the reliability and solid performance of the top line Lutron system integrated and automated with inexpensive sensors, lights, switches, etc.  I had all of this in Premise for 15 years but my automation world changed.  I will continue to check in and read this forum often because of the many great contributors such as 123 whose posts lead me to Home Assistant and MQTT.