Your first NodeJS install

Yup, if things stop working, I'll fire up an old Pi and put a new version of NodeJs on there.

1 Like

My "real" NodeJS is on one of my (5) Mac Mini, which is v12.13 at present.

I have several rPi but the one I am using for experiments is a 3B+ and has node 12.14.1

I can always downgrade Node using n but it's not likely to be a normal part of my testing.

1 Like

@csteele

This old geezer is ready .....

ashok@odroid:~$ node -v
v12.14.1
ashok@odroid:~$ npm -v
6.13.4
ashok@odroid:~$ n --version
6.1.3
3 Likes

Thank you for this. A few months ago I did have Alexa TTS installed but never got the nodeJS server running on my pi3+ to update the cookie automatically. I am not very pi literate and just didnā€™t spend the time investigating further. I have been reading the Echo Speaks thread but havenā€™t pulled the trigger on that install either.

Note: I only purchased my pi to convert a bunch of wifi Teckin Plugā€™s to Tasmota.

I might revisit this now since you have spelled out the steps.

Curious. Without going into a lot of detail, can you point me to the expectations or use case of the upcoming HubConnect that you are talking about? Or should I just wait for it to be released.

1 Like

These two posts by @srwhite provide an answer and illustrate a use case:

3 Likes

NIce. Thanks for the links.

1 Like

Inspired by @dan.t config.json builder for Homebridge, I created a builder for HubConnect Server's config.json.

It's not that hand creating a JSON is hard, but it's fiddly.. comma here, not there, bracket not brace..

56%20PM

It begins as above.. Each Hub within this JSON will need three data values, as shown. As you complete the port value, a new block is added:

When you've entered the final hub, click Copy to Clipboard and then paste that result into "config.json" (all lower case) on your HubConnect Server. There will be an empty block for a next hub. You will want all three values for each hub and nothing in the final empty block.

Try it Here:

17%20AM

Or via the Link here:
http://hubconnect.hubitatcommunity.com/

4 Likes

I'm answering this question here, rather than where you asked it, to avoid hijacking that thread.

I can only say that @srwhite has taken ALL his vitamins.. :smiley: he's come up with more and more things to ADD to the already large v1.7 release he's been teasing.

He's opened a Beta offering and that directly lead him to add yet another feature. (Manifest) To my knowledge, he has not released the code to Beta. As an Alpha tester, I can say that the code is working perfectly, minus some of the tiniest nits I've ever found.

Here's a clue from the alpha repository:
48%20PM

Yep.. 3 hours ago I did some testing.. then an hour ago, I got to start all over. :smiley:

In a high level overview... the 1.7 release will have at least 3 'sections' of feature improvements.

  1. The addition of yet another means to communicate between hubs.. via HubConnect Server, running under NodeJS on an always-on computer.
  2. Improvements in support.
  3. Improvements in Custom Driver

Custom Driver is a feature that is near-and-dear because it's the 'missing feature' of all the similar tools that came before. When new devices come along, there's always early adopters that want to connect them sooner rather than later and for the Platform, that's well handled by Apps and Driver code. HubLink and OtherHub didn't 'see' that future and don't allow for development in the same way. HubConnect has always had the ability to extend itself.

That's great news. I already run a node server so would be very happy to get my hands on this. Are you seeing any latency with sending all events to the node server in terms of filtering, then redistributing back out to subscribing hubs? Will we be able to more easily share devices across hubs or will we still need to do the typical up and over through the HubConnect server? Also, is there anyway we could dynamically load device drivers to remote hubs vs all the manual imports on each hub? Could Reflection be used to build the drivers dynamically based on the original shared device driver? Just want to say thank you for all this hard work!

Just a word of warning...before running two apps on the same NodeJS server, I'd recommend running the new one on a separate docker container or virtual machine or a separate server until you can determine that there are no version conflicts between the two. The last thing you want to do is break your existing app when you install the new one. If one app requires a specific version of a specific node library and the other requires a different version of the same library, you could run into conflicts.

On top of that, the base node version required might be different, which runs into a whole host of other issues.

It's a hard question to answer since your existing latency would depend on what transport mechanism you currently use. For me, transitioning from EventSocket to this new proxy/Server has been beneficial, but I suspect I'm at the low end of the benefits spectrum because I have under 200 devices. As discussed by @srwhite, the EventSocket improvements in v1.5 & 1.6 can cause a hub to see a lot of not useful traffic. I'm at one of the worst extremes of THAT, but even still, it's barely detectable. (One of my Remote hubs sends devices only, gets no devices back. Thus it's seeing ALL of the other hub's events and must discard 100%.) At a high level, I'm going to have to answer... no, no latency issue with the NodeJS transport mechanism.

I've tried HubConnect Server (proxy) on Node v12 and Node v8 (for @aaiyar) and both worked. I didn't try any of the in between Node versions. The Node code I pasted above SHOULD have all the limitations that the 'real code' will and thus it's intended as a good test of coexisting Node apps. I need that myself for Homebridge. I haven't (yet) run into a need to 'get stuck' on a particular version of Node.

No change to the "Hub and Spoke" (aka Server and Remote) architecture. There will always be "total systems" questions that reports instigated from some central device will need to answer. The use of a core NodeJS Server makes the architectural difference potential benefit even smaller.

No... that's a Platform limitation that probably has it's roots in a "smartthings like" platform. Bruce has said no to this query before.

@srwhite has introduced "DeviceMatch" as an alternative selection method. I think we'll see more of that.

Thanks for the explanation. What is "DeviceMatch" in the context of HubConnect?

There in the 2nd Paragraph.

Will there be an upgrade path if I install version 1.6.4 when moving to the node event filter version? Just curious before I set everything up on 1.6.4. Thanks

Yes.

Each version from v1.0 to v.1.6.4 are all upgraded by replacing the code. There's a lot of individual files because at this time, Hubitat doesn't have any 'bulk import' mechanism. Hubitat does have an Import mechanism that takes some of the tedium away, and by doing so, some of the human error. I've created a webpage to assist by having all the URLs used in the import process in one place.

Just copy each line from:

HubConnect Import List

And paste it into the Import field of each piece of code, click Import and then click Save.

The NEXT time, you choose to upgrade, you'll find the Import URL is still there. No need to copy paste :smiley: Just click Import, then Save for each piece of code.


42%20AM

1 Like

I just got the latest Raspbian -- Buster -- and built a 'new' rPi with it and followed these instructions.

They worked:

csteele@raspberrypi2:~/.HubConnectProxy $ node proxy.js   
22:50:40  HubConnect Websocket Proxy Server v2.0.9100
Copyright 2019-2020 Retail Media Concepts LLC
All Rights Reserved


22:50:40  Initializing configured hubs...


22:50:40  Maker socket worker online (PID 1338)
22:50:40  Connection worker for Remote6 online (PID 1340)
22:50:40  Connection worker for Server online (PID 1339)
22:50:41  Remote6: Initializing websocket server...
22:50:41  Server: Initializing websocket server...
22:50:41  Remote6: Connecting to Hubitat websocket...
22:50:41  Server: Connecting to Hubitat websocket...
22:50:41  Remote6: Connected!
22:50:41  Server: Connected!
^C
csteele@raspberrypi2:~/.HubConnectProxy $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
csteele@raspberrypi2:~/.HubConnectProxy $ node -v
v12.15.0
csteele@raspberrypi2:~/.HubConnectProxy $ npm -v
6.13.4
csteele@raspberrypi2:~/.HubConnectProxy $

I didn't expect it to matter and was happy to see it didn't. :slight_smile:

2 Likes

@JasonJoel
Any chance you could explain to me how i can start nodejs in an unraid docker container?
I have tried a few nodejs containers, but none specifically for unraid , and get a bit lost putting the code in. I would love to use this to run the AlexaTTS cookie nodejs application
Many thanks

Start here. There is one other really good node.js docker thread on the unraid forums too. If I run across it, I'll add that here.

3 Likes

Thankyou! I will take s look shortly
Cheers

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.