Thanks for the heads up. Just updated - everything seems ok.
Lots of good stuff in this release.
My favorites:
- $moment in jsonata (finally can have timezone correct time operations!)
- Outliner tree view (although unfortunately sorting options apparently didn't make 1.1 - maybe 1.1.1...)
- Groups
- Inject node can do properties other than msg.payload (YAY!!!!)
4 Likes
Dang, took less than a minute to upgrade. It takes longer than that to upgrade most palettes.
1 Like
I had a mini-panic on mine...
I wasn't intending to update to 1.1 tonight... But when I moved my container from one server to another while doing some other work the system pulled the latest image automatically...
I was scratching my head why it was taking so long to restart on the next server (usually it is a second or two)... Well, it had to download the new 450+ MB image first. lol
Thanks, I did not yet know of this update, and have updated.
Also, repeating a request: can anyone share a Huemagic dashboard flow with a slider/color picker with feedback?
Edit: what is the consensus about websockets? Which is best? Faster? More reliable?
It's different 
It's up to you to test it. If you notice no difference and don't care about the following points, then I suggest to stay with the default behavior (webhook)
Faster: websocket
I observed ~50ms faster with websocket to receive an event
I guess you can easily test it with 2 different config nodes (one using webhook and another using websocket) and compare events
Reliable: Technically, probably websocket (but never hear issues with webhook)
With websocket, in very specific circumstances, you can have delay between reconnect and lose events. But you can have the same issue with webhook (loosing event with connection issue). The only difference is that websocket can notify you that connection is dropped. For now the only notification is on the log (there is no message sent in your flow)
Complete: webhook
websocket event doesn't have all attributes that webhook event has.
websocket can have some duplicate events (see this post)
Supported: webhook
websocket: This resource behavior is an internal implementation of HE. Developers can change it without announcement. Then if the delay between ping/pong or path change, it will break nodes connection.
webhookd: it's the only official documented way to receive event outside HE. I guess that if the implementation change, it will be in the changelog
Secure: webhook (if configured)
websocket: If you enable SSL/TLS for hubitat server configuration, you will have a wss instead of ws connection. But the url remains static and easy to know.
webhook: you can use https with basic authentication
Summary: without starting a debate, since most of us use it on local network, it's not a big point.
8 Likes
If you don't mind me asking, what kind of setup are you using for your swarm(s)?
Swarm 1 -
- 3xRPi4 managers (Raspbian) Note that I have no need for redundant managers, I just did it since I had the RPi4s lying around. If I need an RPi for something else, I'll drop 2x of the managers out of the swarm.
- 3xAtomic Pi workers (Ubuntu 18.04) At <$50ea (including baby breakout board and self printed 3D printed case) these are a STEAL in my opinion.
Swarm 2 -
- 1xCHUWI HeroBox manager (Kubuntu 20.04)
- 2xCHUWI HeroBox workers (Kubuntu 20.04)
Swarm 2 is where all of my production loads are, as the N4100 CPU is noticeably faster than the Atom Z8350.
I used to have RPi4 workers in the mix, too, but I have a number of containers that are x86/x64 only, so thought it was just easier to move all workers to an x86/x64 platform..
Then I have a K3S cluster all RPi4... But I'm having issues deciding on how to to distributed block storage (supportedly and reliably) on K3S, so that is just for testing for now. If/when Docker Swarm ever dies off (which seems inevitable at this point), I'll have to get more serious about moving things to K3S/K8S.
3 Likes
Very nice, thanks for sharing. =)
No clue, that's never happened to me.
Could an outside connection to maker api make that change, or is it strictly a hubitat problem?
You can definitely change it remotely - but it does take the app id# and token to do it (so random external things can't just change it without permission).
Example endpoint change of POST URL:
http://YOUR_HUB_IP/apps/api/YOUR_APP_ID/postURL/[URL]?access_token=YOUR_ACCESS_TOKEN
Where [URL] is the URL you want to set it to.
Ah ha, I bet it’s the hubitat home assistant integration
Could be. You really should have separate maker API apps for each integration.
1 Like
I didn’t even know I would have more than one. THANKsS!
Doubtful. the hubitat home assistant integration requires you to manually configure maker api.
The only thing I can think of that's already setup to change that IP address in maker api is the hubitat node red configuration node. It has a "configure webhook" button that will change the IP to whatever IP address you have in the text box above it.
New to Node-RED and hoping to lighten the load on my Hubitat hubs. This looks like it can help. Looks like HSM and HSM-setter are in the works or are they working and just not in the prod release? How would one get to those assuming I want to live dangerously.
I don't know about dangerously, but I've been getting/setting HSM using http request nodes.
Same, it's really not more difficult this way than with an actual node designed to do it.
1 Like
