Premise MQTT for Premise.

Motorola Premise
chucklyons said:
… with the assortment of drivers and other functionality, why keep Premise on the backend?
Because Home Assistant lacks two important drivers I require:
- HAI Omnistat/2
I have little time or desire to create them for Home Assistant. It's far easier for me to just run Premise and Home Assistant together (bridged via a common protocol, namely MQTT).
- Premise handles all my 'legacy' devices and executes all the automation logic I've developed over the years.
- Home Assistant provides a UI plus functionality unavailable in Premise.
It's not all that different from how others rely on more than one system to provide a complete solution. For example, the last I heard, etc6849 bridged his Premise system with SmartThings and uses its UI to control Premise (and leverage all of SmartThings functionality). Some openHAB and Home Assistant users choose not to use the product's built-in 'rule engine'. They offload it to Node-Red (a completely independent system). In fact, SyseventBroker relies on Node-Red to provide MQTT functionality for Premise. MQTT allows for a level of modularity and inter-operability that was unknown to HA hobbyists a decade ago.
Thanks, 123...Appreciate the data points!
I'll give it a try at some point, no doubt, after I finish my Premise-only polling UI - (because I need to finish this quest! And I apparently love windmills).
I have 6 months to get my RTI work done, so I'll have time shortly.
MQTT is definitely a key to keeping Premise alive. At least until they Open Source it  :wacko:
I've been running a lot of overnight tests with polling, using FF, Edge, and Chrome. My experience is somewhat echoed by a PCWorld article on browser performance. (Opera was #1, then Chrome, Edge, FF)
In my updated Minibrowser version, all the devices are 'active' on the main page. The views use CSS to 'hide' devices, which means they are still polling. However, some devices  ( the 'big' ones - thermostats, mediazones, security systems) can be drilled into. At that point, polling is only active for what is displayed on that page.(e.g. Mediazone - now playing, controls, time, weather, newscast)
I poll 'mbStatus' for each device. mbStatus gets the state for each device. (e.g. mbStatus for Lighting contains on/off state, dimming level, and time of change). The state is put into the respective div tags for each device.
So the list below is what's displayed on the primary page and what is being polled simultaneously:
HVAC         (17 Devices) -  3 Thermostats -( Fan State, Mode, Inside/Outside temps, Temp Set), rain, windspeed, dampers, etc. On/Off, rates and percentages (when applicable)  and time of change (except thermostats). (5 secs)
AudioVideo (4 MediaZones) - volume/mute states, volume level,  groups, group status, source, and now playing. No times. (5 secs)
Lighting       (18 lights and 2 outlets)  - on/off, dimming and times. (5 secs)
Security      (1 security system, 5 zones, 10 sensors and 1 zwave lock) - triggers and times. (still working on the system). (1 sec)
Appliances (4 Devices) On/Off and times. (5 secs)
Safety         (4 devices) triggers and times. (5 secs)
Keypads     (none)
Weather     (from OpenWeathermap) - Temp, Sunset, High/Low Temp, Condition, Icon. (1 min)
Newscast   (from 123) (10 min)
Time           (not polling per se)
All run overnight without issue(s). Chrome is by far the best on memory and CPU usage. Edge is okay - it will soon be based on Chrome, so... FF will run all night, but it seems to be a hog. I changed the disk write time to 30 mins as it was really thrashing my SSD and really isn't necessary for a 'dedicated' UI. I haven't tried any Apple devices. Interval times could probably be adjusted on some things, or maybe restructured a bit. (I'd want volume and mute status fast, but now playing and groups probably could be more than 5 secs)
For my modest place, this seems to be working okay. In reality, visual indicators (White-Normal; Yellow-Info; Red-Alarm) would probably be second in line to audible indicators (Smoke Detector, Siren), so I don't think the lag is too troublesome.
So I am finally getting around to trying this and have hit a snag. 
I setup a VM with Linux and have Node-Red and Mosquitto running on it.  I opened up MQTT-Spy on the host PC and was able to send message back and forth to a terminal window being subbed to a broker matching the Spy.  So far so good. 
Have Node-Red setup but not getting anything into Premise.  I have HASS setup on the same VM now and setup the MQTT broker and ran tests and can see messages getting through Node-Red and converting to Premise messages.  But Premise never sees them.  I see"
"premise/command/home/sams office/overheadLight/powerstate:"
payload: string
sys://home/sams office/overheadlight;powerstate:;1
Any thoughts?
SyseventBroker transmits and receives via TCP port 5100.
When you turn on a overheadlight in Premise, your MQTT client (I don't know what you are using but I recommend MQTT Explorer) should report a payload of "1" published to this topic:
premise/home/sams office/overheadlight/powerstate
and a payload of "100" published to the following topic (assuming it was turned on to full brightness):
premise/home/sams office/overheadlight/brightness
If you see those two topics with the aforementioned payloads, then SyseventBroker is successfully transmitting via port 5100 to the Node-Red flow which is converting Premise's information and publishing it as MQTT topics and payloads to the MQTT Broker.
If you publish a payload of "0" to this topic:
premise/command/home/sams office/overheadlight/powerstate
then the Node-Red flow will convert it to this string:
sys://home/sams office/overheadlight;powerstate;0
and submit it via port 5100 to SyseventBroker. It will parse the string and, if it is valid, turn off overheadlight.
If Premise if not "seeing" the MQTT messages received and converted by the Node-Red flow, then it suggests SyseventBroker is not connected via TCP port 5100. Please confirm its connection. Refer to the instructions I posted earlier explaining how to connect SyseventBroker to the appropriate network port.
123 - Excellent job, as usual (and ETC, I suspect?). Seemed like a daunting installation, but not really. All on Windows 10. Ugh.
I'm did get a "Object required this.ValueProperty' error in "sub gSB_Generic() sJSON = gSB_Header() & _" in the Global Syseventbroker when selecting "Send Status". I deleted all of the new objects I had added for testing MB, and it went away. Not sure of the relationship.
A couple of questions - where do you see the list of supported, unsupported objects? 
On MQTT Explorer, when I make the connection, the connection box stays - is that a config issue? I'm trying to see what MQTT is receiving.
And I haven't figured out how the UI piece fits into the mix i.e. how do you tie the pub/sub events to an interface?
All in all, great stuff! Regret not jumping on it earlier!
Look in Modules > SyseventBroker > Macrosd > MacroFolder. There should be two Macros: ListSupportedObjects, ListUnsupportedObjects.
Basically, SyseventBroker doesn't handle MediaZones, Keypads and maybe one other thing I can no longer recall. It also won't handle any custom Home objects (Modules) you may have created (but it's possible to support them).
I may be wrong but the last time I was in touch with etc, he had been working on extending SyseventBroker to include MediaZones.
I can't comment on the issue with MQTT Explorer. After establishing a connection to my MQTT broker, the connection box goes away and displays a list of all topics currently being managed by the broker.
The UI piece is handled by another system of your choosing.  All that SyseventBroker does is enable Premise to 'speak MQTT':
If Home.Kitchen.CeilingLight.PowerState changes to true, Syseventbroker will automatically publish a "1" to this topic:
If you publish a "0" to:
SyseventBroker will turn off Home.Kitchen.CeilingLight.PowerState
What you use to subscribe/publish to those two topics is your choice. An MQTT client like MQTT Explorer is adequate for confirming all the 'plumbing' is functional. For day-to-day control via a UI, you'll want something with greater flexibility and better presentation options.
  • I started with The Home Remote but eventually abandoned it because I found it laborious to create even a simple UI.
  • I then moved to openHAB. It's a full-blown home automation solution but all I wanted was its ability to create a UI. Ultimately, I abandoned it as well because I ran into a few limitations (and it involved more work than I wanted to invest).
  • I now use Home Assistant. Like openHAB, it's a complete home automation solution but I largely use it to render a UI for Premise. I also take advantage of the things it offers that aren't available in Premise (and probably never will be) like HomeKit integration (for example, I can use Siri to control my UPB lights).
Home Assistant has a few similarities to Premise including the ability to automatically render a UI widget for a Home object (although in Home Assistant it's called an 'entity'). So what I've done is define a matching Home Assistant entity for each Home object I have in Premise. Each one of these entities communicates via MQTT.  The configuration for a light entity would look something like this:
- platform: mqtt
  name: "Kitchen"
  state_topic: "premise/home/kitchen/powerstate"
  command_topic: "premise/command/home/kitchen/powerstate"
  brightness_state_topic: "premise/home/kitchen/brightness"
  brightness_command_topic: "premise/command/home/kitchen/powerstate"

  brightness_scale: 100
  payload_on: "1"
  payload_off: "0"

That configuration tells Home Assistant to create a light called, using MQTT, with instructions for both receiving status and sending commands for power and brightness via the appropriate MQTT topics. It also explains how to convert the incoming/outgoing values (Premise SyseventBroker's 1 and 0) to its own format (Home Assistant uses ON and OFF). It also states that the received brightness values use a scale from 0 to 100 (which Home Assistant converts to its own scale of 0 to 255).
Once it creates the entity, it automatically renders a UI widget for it (like in Premise). Unlike Premise, if you don't like the widget's appearance or its placement, you can change it. You can either change it graphically right in the browser (relatively recent enhancement so it currently has some limitations but is always getting better) or by editing a UI configuration file which offers greater freedom. There's a library of standard widgets ('cards') available and an ever-expanding library of custom cards created by the user-community.
Standard cards:
okay - 
I get the expected behavior when I use the connection. I see a $SYS under that?
For Premise - I have node-red autostart on reboot. When I start manually, it recognizes it has already started and provides info that the ports are in use. good.
For MQTT  client: Name = premisesysevent. No on certificate and TLS. mqtt:// localhost: 5000. Do you have a shot of what the mqtt client should like?
FWIW, the $SYS you see when connected to the MQTT broker at represents its management topics. Although Premise also uses the name SYS, this has nothing to do with Premise.
You wrote that you are attempting to connect to:
mqtt://locahost: 5000
This implies your MQTT Broker is on the same machine as MQTT Explorer (localhost). However, the default port for an MQTT Broker (like Eclipse Mosquitto) is 1883, not 5000. So unless you configured it to use port 5000, you should change it to 1883.
You sir, are correct!   Changing the port to 1883 did the trick on MQTT. SysEventBroker - Port 5100 MQTT - Port 1883 Node-Red - 1880. Premise/command Node indicates "connected". MQTT node indicates connected. 
SysEventBroker commands working as expected (reflects command in the OutCommand TXTextData field)  
Asking stupid questions is apparently an inherent trait, so here we go -  
Where do I see the actual topic information? MQTT Explorer just displays stats on the left side. I don't see anything incrementing as I toggle power on/off? HOWEVER, I do see the messages in Node-Red when looking at the debug log...
As I am hosting everything on a single machine, does that require any changes in the Node-Red flow to display in MQTT Explorer? I would think it would not, as I have connections on both ends of the flows, but I don't really know...
If you turn on a light using Premise Builder, see the resulting command in SyseventBroker's OutCommand, see the message in Node-Red's Debug log, but fail to see it in MQTT Explorer then it suggests the Node-Red flow may not be properly connected to the MQTT Broker.
SyseventBroker --> Port 5100 --> Node-Red flow --> Port 1883 -??-> MQTT Broker
MQTT Explorer --> MQTT Broker 
If MQTT Explorer shows no topics starting with the word 'premise' then it means the Node-Red flow isn't successfully publishing them to the MQTT Broker.
Thanks 123!  This works a treat.  Tested everything back and forth via Home Assistant > MQTT > Node-Red > Premise and back.  Really works well.This will certainly ease my transition.
I have decided to slowly move to a combination of Z-Wave and Zigbee for lighting.  But now I can take my time and do a few switches at a time to minimize the "sting" of the cost.  I am essentially using Premise as a driver for UBP.
Now I need to wrap my head around a totally new way to manage media.  Ugh.
Hmm. I hadn't looked at Pi in a long time. Seems it has come along way!
Home Assistant seems to be more mature(?) than OpenHAB. I've played with it a bit, but don't think I want to invest the time into digging deeper. I have it configured for lights and such, but...
I will say, it is much faster than my Minibrowser version.. :blush:
Sam - which model did you get for your platform?
If you mean what did I install HASS on, I have a VM running Linux Mint and then a Docker instance within that.  Both Node-Red and MQTT (Mosquitto) are running straight on the Linux VM.  Should have done them in a docker instance as well.  But I installed them first and THEN HA.  Not realizing that install HASS via Docker is really the only good way to do it.
The VM is hosted on a Windows 10 PC that runs my new DVR software (Channels) for now.  Eventually, it will all get moved to a Linux server.