OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED

grantlewis said:
OK, so it's not that there's nothing there -- I was just expecting to see something very different. What I need is a delimited log-like listing with all omnilink MQTT activity. With that I could then parse (sort, filter, etc.0 all of the data to find out what unit numbers correspond to which names.
Maybe it's just my setup that it's different, but I see in the MQTT data the NAME=xxxx that is the name i gave in PC Access to that unit, and that is replicated in HA.
That's what I see in HA: all the name are exactly untouched from OmniLinkBridge (I just changed some icons):
https://ibb.co/2qqYWfb
 
grantlewis said:
OK, so it's not that there's nothing there -- I was just expecting to see something very different. What I need is a delimited log-like listing with all omnilink MQTT activity. With that I could then parse (sort, filter, etc.0 all of the data to find out what unit numbers correspond to which names.
Maybe it's just my setup that it's different, but I see in the MQTT data the NAME=xxxx that is the name i gave in PC Access to that unit, and that is replicated in HA.
That's what I see in HA: all the name are exactly untouched from OmniLinkBridge (I just changed some icons):
https://ibb.co/2qqYWfb
 
Ryan,
 
Will the SQL DB record all of the MQTT stuff?
 
I had it set up with the original plugin that only worked with Smartthings way long time ago running it on Windows at the time.
 
# mySQL Logging (yes/no)
mysql_logging = no
mysql_connection = 
 
pete_c said:
Ryan,
 
Will the SQL DB record all of the MQTT stuff?
 
# mySQL Logging (yes/no)
mysql_logging = no
mysql_connection = 
 
Not exactly. It's a separate module inside OmniLinkBridge. It records events from the OmniPro, not from the MQTT module. 
 
rsw686 said:
The code used to arm. disarm, etc is only available in the OmniPro II event log. The OmniLink II protocol only allows polling to read a certain number of events. Currently OmniLinkBridge just sends the area status to MQTT when it receives a notification from the OmniPro II that it has changed. Unfortunately this area status doesn't include the code. OmniLinkBridge would need to poll the event log after it received the area status change notification. Additionally it might need a slight delay as I'm not sure the order of operations that the OmniPro II uses internally. It also might have to read several event log entries to find the correct one. It can be done, but it isn't straight forward.
 
thanks!  I got it working by creating a flag on the omni pro side, turning it on for 60 seconds after that code is used I can then read my node ID using the mqtt node in node red.  If my case the node id is omnilink/unit393/state for the first flag.  The payload is set to ON and then I trigger my alert.  Kinda sucks the limitation but given the rest works so well I am not complaining since it allows me to use all my sensors with HA from my Omni.  I really do appreciate the effort that went into the bridge and allowing us to use it.
 
Quick question,  I didn't realize a flag would show up as a switch in HA which of course now that I think about it makes sense since it was showing up in the MQTT feed from the omnilink.  My question is, I have a node red function that turns on all lights and does this by looking for switch. in the entity_id.  If I exclude that flag in the ini by unit id would it still show up in the omnilink MQTT where I can read from it and it just won't sync to HA as a device or will it hide it from the MQTT feed on the omni side all together.  I think I know the answer but I needed to ask because I want to read it from MQTT but not have it show up in HA.  
 
EDIT - Ignore this question...I figured out in HA I can disable the device and of course then it is still accessible from the MQTT feed from Omnilink. 
 
Thanks
 
jtek said:
Quick question,  I didn't realize a flag would show up as a switch in HA which of course now that I think about it makes sense since it was showing up in the MQTT feed from the omnilink.  My question is, I have a node red function that turns on all lights and does this by looking for switch. in the entity_id.  If I exclude that flag in the ini by unit id would it still show up in the omnilink MQTT where I can read from it and it just won't sync to HA as a device or will it hide it from the MQTT feed on the omni side all together.  I think I know the answer but I needed to ask because I want to read it from MQTT but not have it show up in HA.  
 
EDIT - Ignore this question...I figured out in HA I can disable the device and of course then it is still accessible from the MQTT feed from Omnilink. 
 
Thanks
 
Setting mqtt_discovery_ignore_units only removes it from being auto discovered by Home Assistant. You will still be able to read it from MQTT.
 
pete_c said:
@Ano (Allen),
 
Are you still using the Samsung Smartthings interface piece of the OmniLinkBridge plugin?
 
I recall when I configured your RPi with the OmniLinkBridge plugin last year or year before last that you were still using it.
Yes and no.  Normally yes, but lately, after the newest HA upgrade I have a problem where HA and the whole Raspberry Pi crashes nightly. I'm debugging that. I use SmartThings to manage my Zigbee locks and a few other things that don't work good on Omni Zigee. But not using SmartThings while I debug.
 
I'm still using normal Home Assistant with Raspberrian or what they call that now NOT Hass.io or supervisor, or whatever its called this week, because I could never install OmniLinkBridge on that OS. But you can install the add-in store by adding HACS, so its basically the same thing.
 
Eventually I'll look at Alexa Media plugin in HACS.  Just hadn't had the time. 
 
rsw686 said:
Yes that will override zone 75 so Home Assistant see it as a door. OmniLinkBridge treats all zones the same. It just sends a different device class to Home Assistant. I'm assuming the Home Assistant Alexa plugin is where the difference is coming in.
I THINK this is working. I changed type to "door" and eventually Alexa will allow you to use it as a routine trigger. I have to switch all my Aux zones so this is the case. Alexa seems to categorize devices into many types, but I only see very limited ways to change these. You can make a light a plug or vise versa but not much else. I wish I could change the type in Home Assistant, but don't know how to do that either, unfortunately.
 
|  _ \(_)_ __   ___ / /_ | || |  
| |_) | | '_ \ / _ \ '_ \| || |_ 
|  __/| | | | |  __/ (_) |__   _|
|_|   |_|_| |_|\___|\___/   |_|  
                                 
Welcome to Armbian 20.08.17 Focal with Linux 5.8.16-sunxi64


System load:   24%            Up time:       77 days 21:44
Memory usage:  33% of 1.88G  Zram usage:    23% of 0.94G  IP:            192.168.245.140
CPU temp:      32°C            Usage of /:    19% of 29G   


[ General system configuration (beta): armbian-config ]

Here have 64 bit Ubuntu Focal / HASSIO running on an old Pine64 ARM CPU.  It works.
 

Host Operating System Armbian 20.08.17 Focal
Update Channel stable
Supervisor Version 2021.01.7
Docker Version 19.03.13
Disk Total 28.9 GB
Disk Used 5.2 GB
Healthy true
Supported Unsupported – more info
Supervisor API ok
Version API ok
Installed Add-ons Check Home Assistant configuration (3.6.0), Portainer (1.4.0), Home Panel (1.8.1), TasmoAdmin (0.13.1)
 

Thinking though this is a custom HASSIO build made for Armbian.  
 
Hey all,  The sensors for MQTT that come over like System AC and System Battery.  Can you tell me what those sensors do?  They show OK in Home Assistant.  I was trying to use them to trigger and alert if the alarm looses power and flips to battery.  I pulled the power, waited for the alarm to start yelling at me but the sensors never changed.  They still say ok. 
 
I am adding a flag for now to use that to trigger from the Omni but was just wondering if these sensors should be changing?
 
Thanks
 
jtek said:
Hey all,  The sensors for MQTT that come over like System AC and System Battery.  Can you tell me what those sensors do?  They show OK in Home Assistant.  I was trying to use them to trigger and alert if the alarm looses power and flips to battery.  I pulled the power, waited for the alarm to start yelling at me but the sensors never changed.  They still say ok. 
 
I am adding a flag for now to use that to trigger from the Omni but was just wondering if these sensors should be changing?
 
Thanks
 
They should report the same status as PC Access for AC Power and Battery Low. I'll test it later and see if mine is working correctly. There is always a possibility I have a bug in the code.
 
Starting this all over again due to a machine loss so this time I'm going to Pi4 with external SSD. Plan on running Hass.io on raspbian. I seem to recall the last time I tried this on Ubuntu I could not get docker working so I ended up having OmniLinkBridge running on an x64 box instead. I'd like to have it all contained within the Pi4 this time. I may be back for help :) 
 
cb
 
Here went the opposite way on my new Intel X64 based Ubuntu 20.X automation server.  I installed HASSIO on it via script and it is doing well although not yet production. 
 
I installed OmniLinkBridge via the addon and only had to manually adjust the XML file versus the INI file.  I am liking HASSIO versus plane jane HA installation.
 
HASSIO though is an entire OS running and I am getting used to it running on another OS.
 
Back
Top