OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED
- Thread starter rsw686
- Start date
grantlewis
Active Member
tigers said:
Not a bad workaround, but it's no big deal to just SSH in and paste the command. At present I prefer to keep my finger on the process.
grantlewis
Active Member
Portainer is not Docker. Just because Portainer is not running in no way affects the rest of the system.
grantlewis
Active Member
@pete_c: Did some research. Here's the correct command:
sudo docker run -d -p 9000:9000 --restart always --name portainer -v /opt/portainer-data:/data -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer
sudo docker run -d -p 9000:9000 --restart always --name portainer -v /opt/portainer-data:/data -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer
pete_c
Guru
@tigers,
Typically when you run a docker application or start it; it will auto start on reboot well except for Portainer which did not auto start for me.
Thank you @grantlewis!!!
/opt# docker container ls -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESca54f4fcfe2a portainer/portainer "/portainer" 2 months ago Exited (255) 7 weeks ago 0.0.0.0:9000->9000/tcp portainer2e2d1624611e acockburn/appdaemon:latest "./dockerStart.sh" 2 months ago Exited (137) 13 days ago appdaemon4b986ea7e23a homeassistant/home-assistant "/init" 3 months ago Up 13 days home-assistantd6e6891aaa75 dfarkov/onvif2mqtt "docker-entrypoint.s…" 4 months ago Up 13 days onvif2mqtt8c7d3ee95182 omnilink-bridge "mono OmniLinkBridge…" 10 months ago Up 13 days omnilink-bridge
Tried but need to tweak configuration:
docker run -d -p 9000:9000 --restart always --name portainer -v /opt/portainer-data:/data -v /var/run/docker.sock:/var/run/docker.sock portainer/portainerdocker: Error response from daemon: Conflict. The container name "/portainer" is already in use by container "ca54f4fcfe2a684f60724b7ac4b21b839c0a67b46ee18567966a49f1ee511fb3". You have to remove (or rename) that container to be able to reuse that name.
So started it plain jane way...
/opt# docker start portainer
portainer
/opt# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESca54f4fcfe2a portainer/portainer "/portainer" 2 months ago Up 7 seconds 0.0.0.0:9000->9000/tcp portainer4b986ea7e23a homeassistant/home-assistant "/init" 3 months ago Up 13 days home-assistantd6e6891aaa75 dfarkov/onvif2mqtt "docker-entrypoint.s…" 4 months ago Up 13 days onvif2mqtt8c7d3ee95182 omnilink-bridge "mono OmniLinkBridge…" 10 months ago Up 13 days omnilink-bridge
Noticed here never created a config directory under /opt. Will fix it shortly.
Could not get the Ring=>MQTT plugin working in Docker so manually running it.
Just noticed lost all of my formatting above.
Typically when you run a docker application or start it; it will auto start on reboot well except for Portainer which did not auto start for me.
Thank you @grantlewis!!!
/opt# docker container ls -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESca54f4fcfe2a portainer/portainer "/portainer" 2 months ago Exited (255) 7 weeks ago 0.0.0.0:9000->9000/tcp portainer2e2d1624611e acockburn/appdaemon:latest "./dockerStart.sh" 2 months ago Exited (137) 13 days ago appdaemon4b986ea7e23a homeassistant/home-assistant "/init" 3 months ago Up 13 days home-assistantd6e6891aaa75 dfarkov/onvif2mqtt "docker-entrypoint.s…" 4 months ago Up 13 days onvif2mqtt8c7d3ee95182 omnilink-bridge "mono OmniLinkBridge…" 10 months ago Up 13 days omnilink-bridge
Tried but need to tweak configuration:
docker run -d -p 9000:9000 --restart always --name portainer -v /opt/portainer-data:/data -v /var/run/docker.sock:/var/run/docker.sock portainer/portainerdocker: Error response from daemon: Conflict. The container name "/portainer" is already in use by container "ca54f4fcfe2a684f60724b7ac4b21b839c0a67b46ee18567966a49f1ee511fb3". You have to remove (or rename) that container to be able to reuse that name.
So started it plain jane way...
/opt# docker start portainer
portainer
/opt# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESca54f4fcfe2a portainer/portainer "/portainer" 2 months ago Up 7 seconds 0.0.0.0:9000->9000/tcp portainer4b986ea7e23a homeassistant/home-assistant "/init" 3 months ago Up 13 days home-assistantd6e6891aaa75 dfarkov/onvif2mqtt "docker-entrypoint.s…" 4 months ago Up 13 days onvif2mqtt8c7d3ee95182 omnilink-bridge "mono OmniLinkBridge…" 10 months ago Up 13 days omnilink-bridge
Noticed here never created a config directory under /opt. Will fix it shortly.
Could not get the Ring=>MQTT plugin working in Docker so manually running it.
Just noticed lost all of my formatting above.
Getting back on topic with a little thing I discovered related to OmniLinkBridge and alarm panel in HA. With OPII the automations for alarm arming where triggered immediately as I pushed the "arm" button; that was very convenient for doing some checks on the spot (for instance I had a check that if one of the external doors (garage, garden doors, etc.) were open the arming stopped and the console beeped so I can go and close them before arming.
Unfortunately in HA this is not immediately possible because the alarm component receives the state "armed_night" or "away" only when the timeout has run off. In the meanwhile the state changes to "pending", that if I recall correctly is also the state when the alarm is instead triggered by an entrance before it goes off. There's also the problem of knowing what the "to_state" will be (HA has a function {{ trigger.to_state }} but I couldn't figure out how to make it work properly.
So I came up with a different solution that allows me to trigger and automation immediately when arming, also distinguishing what will be te final "armed" state: it involves a MQTT check on a json message that is update by OmniLinkBridge on arming.
My automation goes like this:
- id: '1591347789736'
alias: Antifurto Notte Attivazione
description: Azioni varie quando si attiva antifurto notte
trigger:
- platform: mqtt
topic: omnilink/area1/json_state
condition:
- condition: template
value_template: '{{ (trigger.payload_json[''mode''] == ''night'' ) }}'
action:
- data: {}
entity_id: group.luci_ambiente
service: homeassistant.turn_off
- ANYTHING ELSE THAT NEEDS TO BE DONE
mode: single
Notes: the "mode: single" on the last line is only form HA version from 0.113 and up (multiple automation triggering has changed a lot - Pete you should check it out since you are running an older version)
The complete json string is as follow:
{
"mode": "off",
"arming": false,
"burglary_alarm": false,
"fire_alarm": false,
"gas_alarm": false,
"auxiliary_alarm": false,
"freeze_alarm": false,
"water_alarm": false,
"duress_alarm": false,
"temperature_alarm": false
}
mode instantly changes to the mode that will be active, arming goes "true" while the system is... well... arming, mode as I have seen can be: "away", "night", "home" (that is "DAY" on the HAI console) and "off".
I can also see some other interesting stings that allow to distinguish the kind of alarm that's been triggered.
Hope this will be useful to someone else.
Unfortunately in HA this is not immediately possible because the alarm component receives the state "armed_night" or "away" only when the timeout has run off. In the meanwhile the state changes to "pending", that if I recall correctly is also the state when the alarm is instead triggered by an entrance before it goes off. There's also the problem of knowing what the "to_state" will be (HA has a function {{ trigger.to_state }} but I couldn't figure out how to make it work properly.
So I came up with a different solution that allows me to trigger and automation immediately when arming, also distinguishing what will be te final "armed" state: it involves a MQTT check on a json message that is update by OmniLinkBridge on arming.
My automation goes like this:
- id: '1591347789736'
alias: Antifurto Notte Attivazione
description: Azioni varie quando si attiva antifurto notte
trigger:
- platform: mqtt
topic: omnilink/area1/json_state
condition:
- condition: template
value_template: '{{ (trigger.payload_json[''mode''] == ''night'' ) }}'
action:
- data: {}
entity_id: group.luci_ambiente
service: homeassistant.turn_off
- ANYTHING ELSE THAT NEEDS TO BE DONE
mode: single
Notes: the "mode: single" on the last line is only form HA version from 0.113 and up (multiple automation triggering has changed a lot - Pete you should check it out since you are running an older version)
The complete json string is as follow:
{
"mode": "off",
"arming": false,
"burglary_alarm": false,
"fire_alarm": false,
"gas_alarm": false,
"auxiliary_alarm": false,
"freeze_alarm": false,
"water_alarm": false,
"duress_alarm": false,
"temperature_alarm": false
}
mode instantly changes to the mode that will be active, arming goes "true" while the system is... well... arming, mode as I have seen can be: "away", "night", "home" (that is "DAY" on the HAI console) and "off".
I can also see some other interesting stings that allow to distinguish the kind of alarm that's been triggered.
Hope this will be useful to someone else.
Hi, I need help in tracking down an issue that could be VERY IMPORTANT: my heating has always been controlled with the OPII, using some temperature sensors in the rooms and accordingly commanding the outputs to turn on and off the zone valves when needed.
Now in migrating to Home Assistant I have setup a series of climate entities that take the temperature data from the MQTT data provided by OmniLinkBrdige.
I set up the system but never tested it since it's summer. What I am seeing is a lot of gaps in transmission of temperature sensors data (the red line are the temperature data):
The gap is very big, from 1 pm to 7 pm roughly, and is never the same for all of the rooms: some are missing none, some are missing different hours, some have smaller gaps:
Other values form OmniLinkBridge seem to come in just fine (hard to tell exactly because apart from temperatures they are all discrete values, but all the automations that rely on PIR data worked fine the whole time). I also can see the values just fine form directly from the OPII so the temperature sensors data are there, it's just that the transmission erraticaly ceases for long periods of time.
As you can see in the graphs they are really gaps, when the temperature is stable I simply get a continuos line, so it's not an issue of MQTT broker not updating the value since it receives the same data.
What could I possibily do to track down the issue?
I'm thinking of a script to restart OmniLinkBridge when a sensor doesn't get data for a while, but that would be far from ideal since I have automations running that need data from the sensors.
Any ideas?
Sorry, don't know why I can't post images even if very small: the pics are here
Now in migrating to Home Assistant I have setup a series of climate entities that take the temperature data from the MQTT data provided by OmniLinkBrdige.
I set up the system but never tested it since it's summer. What I am seeing is a lot of gaps in transmission of temperature sensors data (the red line are the temperature data):
The gap is very big, from 1 pm to 7 pm roughly, and is never the same for all of the rooms: some are missing none, some are missing different hours, some have smaller gaps:
Other values form OmniLinkBridge seem to come in just fine (hard to tell exactly because apart from temperatures they are all discrete values, but all the automations that rely on PIR data worked fine the whole time). I also can see the values just fine form directly from the OPII so the temperature sensors data are there, it's just that the transmission erraticaly ceases for long periods of time.
As you can see in the graphs they are really gaps, when the temperature is stable I simply get a continuos line, so it's not an issue of MQTT broker not updating the value since it receives the same data.
What could I possibily do to track down the issue?
I'm thinking of a script to restart OmniLinkBridge when a sensor doesn't get data for a while, but that would be far from ideal since I have automations running that need data from the sensors.
Any ideas?
Sorry, don't know why I can't post images even if very small: the pics are here
pete_c
Guru
Here relating to HA use both wired HAI temperature / humidity sensors inside and outside of the home.
Adjacent (over kill) to these sensors are 1-Wire sensors talking MQTT.
The two different sensors are very close in accuracy and do indicate how well my combo furnace AC device is operating.
I have a humidfier attached to the furnace and it runs during the winter when the heat causes the home to get dry.
I have a dehumidifier running in the summer when the house gets too humid. I also utilize a whole house electronic filter here.
Many Homeseer users using 1-Wire temperature sensors attach them to the pressure lines of the outside AC compressor and the copper pipes outside of the water heater and pool temperatues for checking operational temperatures.
Adjacent (over kill) to these sensors are 1-Wire sensors talking MQTT.
The two different sensors are very close in accuracy and do indicate how well my combo furnace AC device is operating.
I have a humidfier attached to the furnace and it runs during the winter when the heat causes the home to get dry.
I have a dehumidifier running in the summer when the house gets too humid. I also utilize a whole house electronic filter here.
Many Homeseer users using 1-Wire temperature sensors attach them to the pressure lines of the outside AC compressor and the copper pipes outside of the water heater and pool temperatues for checking operational temperatures.
Hi pete, could you tell me what kind of sensor you are using? Currently I have a couple of DHT 22 with a wire running from to the Arduino that once talked to the OPII and now simply publishes via MQTT some data from sensors. I could recycle the old sensors cables for some DS1820b or use some Shelly1 with sensors but I'd prefer to keep the old setup (so I can have a backup and restart the old automations).
pete_c
Guru
Here hardware modded 3 Sonoff basics series R1 a couple of years ago. Each one is running current version of Espurna firmware.
2 have up to 5 DS1820 temperature sensors. I installed one in the attic with drops to the second floor of the home and installed second one in the basement with runs (up to 50 feet) going outside and to the main floor.
One Sonoff basic connect to a combo Temperature / Humidity sensor in one of the bedrooms. (have humidity sensors on each floor in the house which pair up with HAI combo wired sensor - overkill)
Additionally here modded MagicHome RGB controllers with custom firmware which allows for a digital dimmer on/off switch plus one combo temperature/humidity sensor. Here did under kitchen cabinet LED lighting with thin aluminum strips with diffusers on them and put LED power supplies behind the 120VAC switches in the kitchen near the kitchen counters and put 12VDC "outlets" under the kitchen cabinets.
This is an update to my original 1-Wire hub and spoke network that I had in the house around the late 1990's. Back then used a Midon Temp05, 2 Temp08's connected to cat5e cable which ran all over the house for the 1-wire network.
Thinking some time soon some one will write the entire 1-Wire library to an ESP based device which will be very nice.
All of the above devices talk MQTT. This is the first time I have put my "trust" in wireless MQTT devices. (still have X10, UPB, Zigbee and ZWave here and prefer UPB for my in wall light switches - electric here is in metal conduit and switches and outlets are in metal boxes) I did just install 3 modded Gosund WiFi switches in another home which also has conduit and metal boxes.
Recently installed a Ring alarm system in another home and a RING to MQTT plugin which lets me manage the alarm from a different home and Home Asistant.
The Ring alarm system is all wireless and utilize ZWave sensors.
Rambling now...
Here are screen pics of one 1-wire hub using a modded SonOff basic with Espurna firmware and top half of HA temperature stuff.
[sharedmedia=gallery:images:1392]
[sharedmedia=gallery:images:1391]
2 have up to 5 DS1820 temperature sensors. I installed one in the attic with drops to the second floor of the home and installed second one in the basement with runs (up to 50 feet) going outside and to the main floor.
One Sonoff basic connect to a combo Temperature / Humidity sensor in one of the bedrooms. (have humidity sensors on each floor in the house which pair up with HAI combo wired sensor - overkill)
Additionally here modded MagicHome RGB controllers with custom firmware which allows for a digital dimmer on/off switch plus one combo temperature/humidity sensor. Here did under kitchen cabinet LED lighting with thin aluminum strips with diffusers on them and put LED power supplies behind the 120VAC switches in the kitchen near the kitchen counters and put 12VDC "outlets" under the kitchen cabinets.
This is an update to my original 1-Wire hub and spoke network that I had in the house around the late 1990's. Back then used a Midon Temp05, 2 Temp08's connected to cat5e cable which ran all over the house for the 1-wire network.
Thinking some time soon some one will write the entire 1-Wire library to an ESP based device which will be very nice.
All of the above devices talk MQTT. This is the first time I have put my "trust" in wireless MQTT devices. (still have X10, UPB, Zigbee and ZWave here and prefer UPB for my in wall light switches - electric here is in metal conduit and switches and outlets are in metal boxes) I did just install 3 modded Gosund WiFi switches in another home which also has conduit and metal boxes.
Recently installed a Ring alarm system in another home and a RING to MQTT plugin which lets me manage the alarm from a different home and Home Asistant.
The Ring alarm system is all wireless and utilize ZWave sensors.
Rambling now...
Here are screen pics of one 1-wire hub using a modded SonOff basic with Espurna firmware and top half of HA temperature stuff.
[sharedmedia=gallery:images:1392]
[sharedmedia=gallery:images:1391]
grantlewis
Active Member
Ryan being awesome again -- new OmniLinkBridge version 1.1.9 now available:
https://github.com/excaliburpartners/OmniLinkBridge/releases/tag/1.1.9
Thanks, Ryan!
https://github.com/excaliburpartners/OmniLinkBridge/releases/tag/1.1.9
Thanks, Ryan!
