MQTT for Premise.

123

Senior Member
@Sam
 
You're welcome! I'm glad to hear it's working well for you.
 
BTW, if the price is right, I would be interested in purchasing any UPB gear you wish to sell.
 
FWIW, I continue to use Premise to manage all the things it's been doing well for many years (UPB lighting, ELK M1 Alarm Panel, HAI Omnistat/2 thermostat, etc) combined with Home Assistant for the Lovelace UI, HomeKit integration, etc. The two systems communicate via MQTT and share responsibilities. As I see it, it's not all that different from people who choose to combine Home Assistant with MQTT, Node-Red, zigbee2MQTT, etc.
 
@Chuck
Home Assistant has been around for 6 years now. My impression (based on circumstantial evidence) is that openHAB is at least that old if not older. The primary difference is that Home Assistant still claims to be in beta mode (no 1.0 release yet) and the release cycle is much faster (it used to be every 2 weeks; recently slowed down to every 3 weeks) compared to openHAB (twice a year).
 
FWIW, I've used both and I prefer Home Assistant mostly because it uses the same 'Home objects' paradigm as Premise (albeit not nearly as sophisticated as Premise). Both use 'higher-order' building blocks like sensors, switches, locks, fans, alarm control panel, etc.  In contrast, openHAB uses some 'higher-order' building blocks (rollershutter, player, etc) and more rudimentary building blocks like number, string, switch, dimmer, etc. Plus Home Assistant can automatically create a basic UI (like Premise) whereas in openHAB you have to define it from scratch.
 

chucklyons

Active Member
I have to say, openHAB works well with my Lutron RA2 and a couple of other things. So far, and I admit I'm in preliminary mode,  I don't see ELK support? Your Elk Premise implementation is/are supporting my home(s) extremely well! So if openHAB doesn't support it....and I get the MQTT connection (I still have some troubleshooting to do!), I have a lot of hesitation embracing openHAB...
 
I do take a little pride in what I had in my UI vs Home Assistant. For instance, I implemented IFrames (like Home Assistant) for things, like Rachio. Contro, but of course, zero integration with Premise...or anything else.
 
In both cases, openHAB and Home Assistant, it (I'm obviously biased) emphasizes how far ahead of its time Premise is/was. And as far as I can tell, none have the concept of groups for media...(Sorry, Sam!)
 
My immediate takeaway from openHAB was manually creating the UI. Not good!
 

chucklyons

Active Member
Sam -
 
Did you create the VM using the Windows HyperV? Or something else? I see HA runs on Ubuntu, which is available as a Windows service? That would suggest the both Premise and HA can be run on that same machine...
 

samgreco

Active Member
I use Virtualbox.  Not a fan of Hyper-V.  Haven't tried Ubuntu as a service yet.  Probably should though.
 
Virtualbox can be a bit convoluted as far as auto-starting a VM.  And auto-starting as a headless VM.  But once it's setup, it works well and seems to be a bit less resource hungry than Hyper-V.  And that would still allow Premise to run on the same PC, providing it's a Windows host.
 
I am actually working towards moving off of Premise entirely eventually.  And looking to move everything to a Linux PC.  I just haven't made the final decision.
 
I've been working with Home Assistant and have mixed feelings about it.  It's fairly kludgy in a lot of ways.  Just getting it setup for Google Assistant is a pain.  Still not working.
 
But it's talking to Premise nicely! :)
 
I won't even start on media stuff....  Ugh.
 

chucklyons

Active Member
I think I've done some due diligence. My high level observations.
 
I looked at RTI. Worked with the controller. My impression is that it by and large was a great remote that was expanded to be more. It's foundation was maybe good for simple remotes; not so much for a broader 'Home' configuration. Maybe I'll go back to it and spend some cycles on it.
more 
C4 - definitely the cream, although I haven't looked at Crestron/AMX in a long time. I contacted 6 dealers. Only 2 responses. Dealer #1. Need to do a grounds up rework, starting at NW and beyond. Full system. Way too expensive. No way to be given extra access to let me dig in. Dealer #2 - more reasonable, but about $4K for the controller, a Homeowner's access (I can make my own schedule changes!) module, and some training.
 
Alexa or Google would give me as much 'automation' as I need if I'm only going to have Homeowners access.
 
So I guess we're stuck with varying degrees of kludge....or pay $$$ and be done with it.
 

samgreco

Active Member
I gotta tell ya, I'm kind of digging getting everything working in HASSIO.  I thought I'd hate all of the YAML editing.  But it's really quite simple. 
 
I now have a 1/2 dozen Zigbee bulbs (the IKEA ones of which they are closing out a few models) mixed with my UPB stuff from Premise all working with Google Home.  I have most of my lighting grouped by room in HASSIO  as well.
 
Although figuring out scenes (Automations) feels daunting.
 
Meanwhile, I'd like to bring my Premise scenes into the mix for now until I rewrite everything in HASSIO.  I'm stumped.  Not even sure where to start.  Any help on that front would be appreciated.
 

123

Senior Member
Do you want to:
 
Turn your Premise scenes on/off from Home Assistant?
 
OR
 
Convert your Premise scenes to Home Assistant scenes?
 
 
If it's the first, then create an MQTT Switch in Home Assistant and follow this example (the scene's name in Premise is EveningExterior):
 

- platform: mqtt
  name: "Evening Exterior"
  state_topic: "premise/scenes/eveningexterior/play"
  command_topic: "premise/command/scenes/eveningexterior/play"
  payload_on: "1"
  payload_off: "0"
  state_on: "1"
  state_off: "0"

If it's the second, the documentation provides examples: https://www.home-assistant.io/integrations/scene/
 

pete_c

Guru
@123
 
Redoing the climate stuff for the OmniStat2 thermostat MQTT stuff here to build a card as it doesn't work any more with the old stuff.
 
So building the thermostat card with the MQTT messages.
 
Did you build a climate configuration in the configuration.yaml file for the thermostat?
 
I have tried this one and it errors when starting.  I know my nomenclature is incorrect.  Can you please help?
 
climate:
  - platform: mqtt
    name: thermostat1
    current_modes:
      - "auto"
      - "off"
      - "cool"
      - "heat"
    fan_modes:
      - "auto"
      - "on"
      - "cycle"
    hold_state:
      - "on"
      - "off"
    mode_state:
      - "cool"
      - "heat"
      - "auto"
      - "off"
    min_temp:
      - "45"
    max_temp:
      - "95"

    fan_mode_state_topic: "omnilink/thermostat1/fan_mode_state"
    fan_mode_command_topic: "omnilink/thermostat1/fan_mode_command"
    hold_state_topic: "omnilink/thermostat1/hold_state"
    hold_command_topic: "omnilink/thermostat1/hold_command"
    mode_state_topic: "omnilink/thermostat1/mode_state"
    mode_command_topic: "omnilink/thermostat1/mode_command"
    temperature_high_state_topic: "omnilink/thermostat1/temperature_cool_state"
    temperature_high_command_topic: "omnilink/thermostat1/temperature_cool_command"
    current_temperature_topic: "omnilink/thermostat1/current_temperature"
    temperature_low_state_topic: "omnilink/thermostat1/temperature_heat_state"
    temperature_low_command_topic: "omnilink/thermostat1/temperature_heat_command"

#    current_operation_topic: "omnilink/thermostat1/current_operation"
#    current_temperature_topic: "omnilink/thermostat1/current_temperature"
#    temperature_heat_state_topic: "omnilink/thermostat1/temperature_heat_state"
#    temperature_cool_state_topic: "omnilink/thermostat1/temperature_cool_state"
#    mode_state_topic: "omnilink/thermostat1/mode_state"

Extracting topics from MQTT explorer.

See this in my HA logs:

2019-10-18 22:16:27 ERROR (MainThread) [homeassistant.config] Invalid config for [climate.mqtt]: [current_modes] is an invalid option for [climate.mqtt]. Check: climate.mqtt->current_modes. (See /config/configuration.yaml, line 201). Please check the docs at https://ho$
2019-10-18 22:16:36 ERROR (MainThread) [homeassistant.components.mqtt.climate] Exception in async_discover when dispatching 'mqtt_discovery_new_climate_mqtt': ({'current_temperature_topic': 'omnilink/thermostat1/current_temperature', 'temperature_low_state_topic': 'omn$
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/mqtt/climate.py", line 244, in async_discover
config = PLATFORM_SCHEMA(discovery_payload)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)

I know my approach to this is totally incorrect and should be using an updated climate.py file.
 
 

123

Senior Member
Pete,
 
With all due respect, this thread is about using MQTT with Premise. Your question is about Omnistat/Omnilink/climate integration is off-topic (and there's a dedicated thread for it elsewhere … where you are currently participating). I don't own an Omni panel nor use the Omnilink component. However, I'll do my best to answer your questions.
 
 
The error message says it all:
 
[current_modes] is an invalid option for [climate.mqtt]
 
The default MQTT HVAC integration doesn't support a "current_modes" option. My guess is that it's an option supported by the Omnilink custom component. However, for some reason, that custom component did not get loaded and so Home Assistant is using the default one (MQTT HVAC) and subsequently carping about the existence of 'current_modes'.
 
Tried it anyhow with 0.98.4
and see this:

Configuration invalid
 
If you're referring to trying the OmniLink custom component in 0.98.4 then that error message indicates the component was not updated to support the architectural changes introduced by the so-called "Climate 1.0" initiative. In short, the custom component appears to be incompatible with recent versions of Home Assistant. You'll need to bring it to the attention of the Omnilink component's developer (via the GitHub repo or the other thread).
 
Good luck!
 

samgreco

Active Member
@123
 
Just wanted to says thanks for all of your help.  You've pointed me in the right directions on Premise and HASS.IO.  And thanks for syseventbroker.  You've got me rolling along very nicely now.
 
I ended up using scripts instead of automations and it seems that most stuff is working well.  I will probably be poking my head up on the HASS forums for more guidance on things.  But there really is a ton of info out there already.
 
Still left:
Convert all of my scenes from Premise to Hass scripts
Learn Lovelace
Figure out media and zones using my matrix, for which there is no driver (Vaux Lattis LA-1600E)  :(
and all of the stuff that I don't know I need yet :)
 

123

Senior Member
You're welcome!
 
 
A few thoughts:
  • Home Assistant's scripts provide more flexibility than its scenes. The same is true for Premise. A scene is strictly 'set this thing to on, this other thing to 50%, yet another to off, etc' whereas a script also allows you to do some conditional logic (if this thing is on then turn the other thing to off).
  • Home Assistant's scripts aren't nearly as flexible as they can be in Premise where it's whatever can be achieved with VBscript (which is a lot). To match this level, you would have to use Home Assistant's python_scripts which, naturally, use python.
  • Be advised that you can't execute a script if it's already running. In other words, scripts run in blocking mode … and they allow for delay statements. So a script that pauses itself for umpteen seconds, minutes, or (gulp) hours,  will block all subsequent attempts to run it during this period.
  • The default way to customize the Lovelace UI is within the browser itself (i.e. GUI editing). However, it currently has limitations so if you bump into them you must 'graduate' to editing the ui-lovelace.yaml file directly.
  • The Lovelace UI offers many (many!) custom cards. Each one of these cards is described in the individual author's GitHub repository … meaning all these cards are all over GitHub. To address this "no single library of user-submitted content", the user 'ludeeus' created a utility called HACS. You need a GitHub account because HACS uses it to scan though eligible GitHub repos (the first scan is lengthy) and present a consolidated, categorized list of Lovelace custom cards, custom components, and other user contributions. After you've familiarized yourself with the core set of 24 Lovelace cards, you may wish to use HACS to explore the wider universe of available cards.
  • Personally, I no longer use a wall-mounted touchscreen and I rarely refer to the Lovelace UI via my phone. When I do, the UI I've created is spartan. For example, I don't show doors that are closed, only the ones that are open plus a badge that reports the number of open (exterior) doors. I'm awaiting the release of an enhancement (in the pipeline) that will allow me to hide the badge if all doors are closed. This adheres to my preference of only showing information when it is pertinent (i.e. if the 'doors open' badge isn't shown then, naturally, no doors are open).
  • You may wish to send a PM to ETC and ask if he ever enhanced SyseventBroker to support MediaZones. The last time we spoke he was using SmartThings with Premise and planned to control MediaZones with it.
  • FWIW, writing a custom component (i.e. a driver) in Home Assistant is much more involved than creating it as a Module in Premise. It's more like writing a native Premise driver (in C++). My benchmark is this: it took me a few months (~3) to create the ELK M1 driver, as a Module, and it was my first significant Module and I did it as a complete newcomer to Premise. In contrast, it took about a year to develop Home Assistant's ELK M1 integration and the thread containing the back-and-forth during its development is hundreds of posts long. I skimmed through its python code and, despite everything I already know, I seriously doubt I could duplicate it on my own within 3 months! 
 
Good luck, keep us posted, and see you in the Home Assistant community forum!
 

pete_c

Guru
Thank you 123.  Thought that you had an OmniPro  / Omnistat / Omnilinkbridge in place.
 
Understand about posting under said OmniLinkBridge OP.
 

samgreco

Active Member
So, I've decided before I go too much further, I should really give OpenHab a fair shake.  I've copied the Premise items file and transform files over.  Enable MQTT binding and now....  not sure?
 
123, can you point me in a direction to get my Premise stuff into OpenHab?  Should the items populate "automagically" with the .items file?  Or do I need to put each dimmer and such in manually?
 
I found HA to be fairly straight forward.  But the media side is giving me fits.  So I'd like to see if OpenHab is easier for me to understand that stuff.
 

chucklyons

Active Member
Sam, I started on OpenHab I'll remote in and refresh my memory on my items file.
My biggest obstacle with OH is lack of support for Elk.
I do have to say that some of the moderators on the OH seem to be of some royal lineage, or so they seem to think. It REALLY turned me off. At first, I thought my post was read incorrectly, but then I saw a response from another moderator to another user and it was twice as nasty.
Now I get what ETC was stating some time ago...
 
But, I do/did like the UI, I was starting to get the concept and it was fairly straightforward. But the moderators...Or maybe you guys have just spoiled me on posting etiquette  ^_^
 
Top