It's not entirely clear what you're trying to do. While it's possible to exec commands into a running container, and even install software, this typically would only be done for troubleshooting. A container should be built containing all the software it needs to run. Look at "Dockerfile" documentation for how to build a container. It's extremely uncommon to build a container completely from scratch, which means you will typically start by building upon somebody else's base container. That base container will dictate the file structure and command requirements within the container.
I've been playing with dockers recently on my unraid box.
Maybe you want to do a "docker run -it [dockername]". I do that to create the container and drop me to an interactive shell that I can play around in. Then you can run your other commands.
This is the anti-pattern to the use/purpose of docker and containers. A container is meant to be well... a container. Self contained, single purpose, start and run. You're not meant to open a shell to it or debug it or change the contents. Doing so defeats the whole purpose.
From a "end-user" perspective you find a container to meet your needs and run it. From an admin perspective you build the container which is much more involved and is done usually from a linux system where a micro-image plus app/binary are packaged into the container for distribution/run-time.
Yes, I have some reading to do.
In Debian I would just download the repo, type npm -g install, add the config.json file and run it in a shell. Totally different, I see.
You can build a container, based on debian, and then for the most part, use your same commands you would normally use in debian as run commands.
One more note. It's typically best not to reinvent the wheel. First check to see if the work has already been done for you.
Node publishes an official container, and it appears to be based on debian besides.
That would do it I think, but is it run only, or can you install in debian after you build the container? He would be running this on an unraid box just like @gavincampbell. It's a small node.js app named insteon-server by Scott Kuester that communicates with the Insteon hub and allows HE to control lights and dimmers. Just need that to run in a docker, how ever that works.
So you're still going to want to build your own container that contains the app, but you can use the official node container as your base.
The first line of your Dockerfile will be FROM: node
Then RUN apt install insteon-server
Then CMD /usr/bin/insteon-server (or whatever the binary for the server is)
You would then docked build the new container, and the docker run the container, you'll want to read the docs on docker run as well, you'll probably want to pass in your config.json as a volume, and you'll need to expose a port
Ok so now I'm wondering about distribution. I don't want to be redistributing Scott's software without permission. Need to ask him about maybe creating the docker container.
So, tyoically, you would only distribute or share the Dockerfile, which is essentially the recipe to build the container, then let the end user build it themselves.
Not exactly. Docker Hub is the typical medium for distributing a container. The average user won't have a docker build environment normally and definitely NOT on a unraid or synology system that is just a runtime environment.
Thanks. I'll ask Scott about it. I really don't understand docker and really don't have a use for them myself. I'm just trying to help out @rgreenpc with this. He and I are both Insteon users. I have tested for Scott before, so know something about the software and how to install it on Debian or FreeBSD, but docker isn't something I've dealt with.
Having said this though, @rgreenpc you might try just installing the insteonlocal plug-in on the Homebridge docker you have. That might work just fine with just Insteon devices. There was an issue I was having with the Homebridge app enabled and slowing of the hub. Tonight I'm testing beta software and so far the issue is gone. I'll know better at 2:06am when the hub database rebuilds.
I use an ISY for my insteon stuff and I have a working nodeserver integrating Hubitat devices with ISY. I just received an Insteon Hub to start poking to see if there's a clean route to integrate it. Most likely the cleanest is using the existing external server solutions which actually make a lot of sense really. Using the external system like an rPi to handle the middle man translation and "heavy lifting" of the integration and then having a lightweight websocket client app running on Hubitat to receive the events and send back the basic on/off/fon/foff etc to me makes a lot of sense.
Using one or multiple rPi's or even full servers to offload/process integrations and then have a very thin layer interface between the controller and the processing system. Very efficient and completely distributes the computing (cpu, memory, disk io, network io) off/away from the controller (hub) system. This is the methodology that "Professional" systems utilize. It offloads the processing and adds an isolated layer between the primary controller and any "plugins/apps" which adds a very nice layer of protection preventing a bad app from taking down the entire system. Even Home Assistant has taken up this model with HASSIO utilizing docker and the HASS ADDONS each being their own container. It provides an isolation layer... but with HASS it's still all on the same rPi so it does nothing for distributing the workload.
The app that Scott Keuster wrote utilizes Home Controller used on HA. He recently added websocket support to the insteon-server node app. So exactly what you're describing is possible. @cwwilson08 has been working on a driver, but I'm sure contributions are welcome. There's an error that hasn't been resolved yet. It's very close and we'll have contacts, motion sensors, and leak sensors, We already have dimmers and switches.
I've come to rely on this completely. It's rock solid. Super fast and I get to keep all of the great hardware features of the Insteon products. Only thing you need the Insteon cloud for with the 2245 hub, is devices setup. After that, it can go offline and it doesn't matter at all. All your devices operate super fast with HE locally. I'm very happy with this setup. Looking forward to the input sensor capabilities.
I'm waiting for my new Hubitat hub and want to get ready.
All lighting is Insteon with ISY. I'd like to keep lighting on ISY as it was rock solid for years. I was searching for integration solution with HE but still not clear on the best path. I'm currently on ST but want to switch to HE for many reasons. With ST I just make few REST calls to ISY and back using WebCore pistons. It is not really a full 2-way integration I'm after.
Do I have to but Insteon hub just for one-time setup? Can I possibly utilize Web portal I'm subscribed on ISY to do the same?
I have a capable Synology NAS with docker support. Anyone with experience setting ISY integration Node on it?
Is integration code public and where can I find it? I don't mind contribution to pay for someones' time.
Ideally I don't want to introduce any more nodes, middle layers unless I must.
The code you’re referring to was written to work with the Insteon hub. However, @jeubanks wrote something for ISY, but I don’t believe it’s public, and I cannot speak to it or if he is willing to share the code. Doesn’t hurt to ask.
A Polyglot NodeServer for the ISY was developed which integrates Hubitat with the ISY environment. This is a bidirectional interface from the ISY allowing status and control of devices from Hubitat. Meaning your Zigbee or Z-Wave devices in Hubitat are available for use within the ISY system for programs and scenes.
The Nodeserver is available via Polyglot but it has not been updated in a while but should still be working. Not all devices are supported as I don't have every device to test with so things are going to be missing and things are added/updated as requested.
Thanks for answering my question.
Is this the one?: https://forum.universal-devices.com/topic/25970-polyglot-hubitat-elevation-nodeserver/?tab=comments#comment-259615.
It looks like one-way - HE to ISY per description. Is this correct?
It is to present HE devices to the ISY. NOT Insteon to HE.