Live data from Hacker News

Node-RED: Low-code programming for event-driven applications

nodered.org

71–80 of 93 posts

Re: Node-RED: Low-code programming for event-driven applications

#71
Since I've been asked a couple of times in the threads for Node-RED examples, here's my home automation write up from a couple of years ago:

https://taoofmac.com/space/blog/2019/01/13/1900

These days I've changed the setup a bit and now take advantage of Node-RED's debugger plugin and Projects/git features, but the rest still applies.

Re: Node-RED: Low-code programming for event-driven applications

#72

Earlier quoted context omitted.

I wish I could figure out how to de-automate my bathroom light. It tends to wrongly notice that I've left the room leaving my in total darkness. My workaround is to leave the light on in the adjacent closet, which, for some reason has no such amenity. I doubt a lifetime of saved button pushes would ever make up for the inconvenience of troubleshooting this not-quite-smart-enough light system. But other people have di…

This is the thing that’s kept me from pursuing home automation: the advantage of automating lighting (or anything else) is completely negated the moment something goes wrong, because you’ll spend more time debugging than you ever did flicking the light switches in the first place.

It's not completely negated, depending on the case.

The kitchen in the place I rent has this island (its more like a peninsula) that just barely makes the light switch for the kitchen out of reach, so instead we have to walk around the way around.

Obviously a manageable situation, but automating things has been a covid hobby. So I automated the lights, obviously, via replacing the light switch and added a motion sensor to the kitchen wall. There's also an echo dot for voice control.

Walk into the kitchen, lights turn on, eventually they go off. If they don't go on, just say "alexa turn on kitchen" and they go on, motion detector eventually picks up and turns them back off.

Use the light switch, and it disables the motion sensor for an hour and just leaves the lights on, or off, whichever direction was pressed.

Time saved for everyone not walking back and forth, also at night, has definitely been greater than time spent for me debugging.

YMMV

Re: Node-RED: Low-code programming for event-driven applications

#73
Some past threads. Others?

Node-RED 2.0 - https://news.ycombinator.com/item?id=27892226 - July 2021 (62 comments)

How-to normalize home volume levels with Node-RED - https://news.ycombinator.com/item?id=23349902 - May 2020 (28 comments)

Node-Red – Flow-Based Programming for the Internet of Things - https://news.ycombinator.com/item?id=18859019 - Jan 2019 (77 comments)

Replacing a Pool and Spa Controller with Raspberry Pi, Arduino, Node Red - https://news.ycombinator.com/item?id=18142335 - Oct 2018 (3 comments)

Node-RED: A visual tool for wiring the Internet of Things - https://news.ycombinator.com/item?id=13495156 - Jan 2017 (6 comments)

Node-Red, a tool for wiring together hardware devices, APIs and online services - https://news.ycombinator.com/item?id=8419984 - Oct 2014 (8 comments)

Node-RED - https://news.ycombinator.com/item?id=8310536 - Sept 2014 (1 comment)

Node-red, a visual tool for wiring the Internet of Things - https://news.ycombinator.com/item?id=8217664 - Aug 2014 (3 comments)

Programming the Missing Links in the Internet of Things - https://news.ycombinator.com/item?id=6459564 - Sept 2013 (1 comment)

Re: Node-RED: Low-code programming for event-driven applications

#74

Earlier quoted context omitted.

I wish I could figure out how to de-automate my bathroom light. It tends to wrongly notice that I've left the room leaving my in total darkness. My workaround is to leave the light on in the adjacent closet, which, for some reason has no such amenity. I doubt a lifetime of saved button pushes would ever make up for the inconvenience of troubleshooting this not-quite-smart-enough light system. But other people have di…

This is the thing that’s kept me from pursuing home automation: the advantage of automating lighting (or anything else) is completely negated the moment something goes wrong, because you’ll spend more time debugging than you ever did flicking the light switches in the first place.

I've been very conservative in uses of automations like that. A couple ancedotes:

The outside lights on the front of my house have a motion sensor. Alone, they turn on to about 50% at dusk, and off at 11:30. If there's any motion between dusk and dawn, they go to 100%, then eventually fade back to 50% or off depending on the time. They also come on (and stay on) at 100% if the garage is open. End result: they are at 100% when useful, and otherwise at 50% don't (annoyingly) shine as much into the front windows.

I also experimented with turning down the kitchen lights when there's no motion. The effective of this was described to me as "What did you do to the kitchen lights?! They just randomly turn off and it's driving me crazy!" -- even not in the room, the lights in an adjoining room turning off unexpectedly was bad. End result: Motion controls removed.

There's also some simple time-based controls. If no lights have been manually adjusted recently, at dawn a couple lights come on (to make it look like someone's home) and likewise turn off sometime later at night. There's also an absolute off at 3am, and again at very early dawn. These have the effect of never coming home to a dark house and never leaving lights on all night.

The best automations blend in so you don't even notice them. But absolutely make sure humans can still control things, and don't do things that interfere with that control or expectations.

Re: Node-RED: Low-code programming for event-driven applications

#75
post #67
post #50

This software is great on the esp8266 and esp32 series of microcontrollers for those who like to tinker.

Erm. You can't run Node-RED on those, the NodeJS runtime alone would eat three times the flash storage. You can _talk_ to them, though, from a more powerful system.

Sorry I meant in concert with. I run node red on a raspberry pi and then send it stuff from the esps. My brain was thinking the right thing and my fingers didn't type it. You're absolutely correct.

I have them send MQTT to Node Red.

Re: Node-RED: Low-code programming for event-driven applications

#76

Node-RED co-creator and project lead here. Happy to answer any questions you have.

I'm a big Node-Red fan, been using it for years to automate and do lots of neat things. One problem I kept coming back to was trying to create dynamic urls for websockets. I'm curious if that might be on a future roadmap for Node-Red?

Re: Node-RED: Low-code programming for event-driven applications

#77

Earlier quoted context omitted.

There are fantastic reasons why it should not be allowed on random local devices, unless the local device is configured with some sort of authentication... but the problem now is that total ban on accessing local devices from a secure web app is a serious choke point for anyone trying to develop something to control appliances outside the walled garden. Fascinating discussion here with a Plex dev expressing similar f…

Dumb question. Why not just get a free subdomain and get a letsencrypt certificate for each device? https://community.letsencrypt.org/t/dns-providers-who-easily...

Valid question. The devices are in shops all over the country and should be able to run autonomously. I don't want to get into the business of remotely managing those machines, setting up certificates and DNS on each one, especially since I have no control over the routers in the shops. Supporting the app is hairy enough without trying to do tech support for each shop's network issues.

Re: Node-RED: Low-code programming for event-driven applications

#78
post #40

I have just been going through a HELL of a time building a web-based app ("PWA" in progressive lingo) that needs to auto-discover certain devices on the user's LAN. This is a rebuild of an existing AIR-based app that's been in use in a corporate setting for 10 years and needs to be replaced because "death of flash". The AIR app I wrote back then handled discovering the local devices fantastically well. The problem no…

We're a industrial-control company whose traditional UI has been standard win32 applications - we've slowing converting our stack over to a web interface but as our UI needs to talk to lots of local devices, we've hit the problems you described. Our solution has been to basically mandate that the user install either a small embedded device (ie. RPI or equiv) or manually launch a container. These essentially just serv…

That's cool. I guess our problem could be described as allowing non-technical users to control the in-shop devices from an app on their phone (both android and iOS) without knowing the local IP at all. Like, how do we determine the shifting dynamic IP of our in local routing system from an app served from the cloud ...and the answer unfortunately is we can't. We have to serve the app locally in each facility.

Re: Node-RED: Low-code programming for event-driven applications

#79
post #25

If you're interested in something more generic, check out if https://enso.org could be worth a look! Thanks to GraalVM, you might be able to import JS packages too, among others (Java, Python, & more...); OTOH with the caveat that the project is still in ways in-dev...

I've been following Enso since it was Luna. Can you be a bit more explicit about 'in-dev'? Not to be used yet in production? Thanks.

Hm, honestly, this was kinda precautiously overly-defensive statement from my side. I mean, I'm also following Luna/Enso with huge interest, but it's kinda on-and-off for me; it seemed to me to still have some rough edges in the GUI last time I checked, but also it was quite long ago already - somewhere right around their 2.0 public announcement, in January 2021. No slightest idea at what state the GUI is now, or the libraries; haven't had time to approach it again since. But I expect to do that quite soon.

Re: Node-RED: Low-code programming for event-driven applications

#80

Earlier quoted context omitted.

I wish I could figure out how to de-automate my bathroom light. It tends to wrongly notice that I've left the room leaving my in total darkness. My workaround is to leave the light on in the adjacent closet, which, for some reason has no such amenity. I doubt a lifetime of saved button pushes would ever make up for the inconvenience of troubleshooting this not-quite-smart-enough light system. But other people have di…

This is the thing that’s kept me from pursuing home automation: the advantage of automating lighting (or anything else) is completely negated the moment something goes wrong, because you’ll spend more time debugging than you ever did flicking the light switches in the first place.

The only thing that's tempted me when it comes to automation is whole-house light dimming past a certain hour. But AFAIK that would require buying a whole bunch of really expensive bulbs (or, otherwise, re-wiring a bunch of stuff), so I've passed on it for now.

If you get used to candle or other low-power nighttime lighting, typical house lighting seems obnoxiously bright. I'm convinced it's a major contributor to the sleep troubles that, it seems, nearly everyone in the modern "West" has. It's way more light than you need to get around, play board games, play or listen to music, read, et c. It's like we're trying to make our houses as bright as they are in daytime, which seems like it'd have to be really bad for sleep.

I'd just put dimmer bulbs in all around and forget about automation, but I kinda do want the daytime-like brightness for at least 2-3 hours after sundown, in Winter, or the option to turn it back to full brightness if I've got people visiting and they don't like it (it's not that way so you like it, it's that way so you get sleepy when you're supposed to—but whatever)

Post reply on HN