Node-RED nodes for hubitat

It can happen if you had changed the name of your device in HE and leave the NR name empty.
Then each time you'll open a node (with a device) it will fetch the new name and mark the node as dirty
To see what changed, you can look at the node attributes (without double clicking on it)
ex:


Then double click on the node and see what's changed

2 Likes

Oh I agree, when you used to use single attribute, you can expect to see the same behavior with the all attribute :thinking:

1 Like

I use Node-RED to schedule lights on/off and I was looking for a way to account for seasonal shifts (DST, longer/shorter daylight hours). I have light sensors that I currently use to turn the lights on/off during the day if it is cloudy and I thought I could use the same devices to turn on lights after a certain time (sunset - 60 mins) if the lux reading goes below a certain threshold. I currently have the triggers as offset from sunset, but the light levels are not consistent across the months, so the lights come on when not needed in summer or come on when it's too dark during winter (unless I fiddle with the offset number).

Test flow is below:

Thoughts on this? Is there a better or simpler solution to this? Thought I'd ping the collective before I went down this path :grinning:

The bigtimer node has options for sunset/sunrise + offsets so this may be your best bet.

3 Likes

I am currently using a node that has sunrise/sunset and offsets. The issue is that the offsets need to change. The light level at sunset -60 in winter is much lower than sunset -60 in summer..

2 Likes

Which is precisely why I ditched time-based lighting in favor of reading the actual level at the moment. I use one of @iharyadi's Hubitat with Homemade Temperature, Humidity, Pressure and Light sensor for this. Not only does it make the day of year irrelevant, it also turns on my lights earlier if it's cloudy.

3 Likes

You can change the offsets by month. Or, at least select month in the initial node, and then send it out one path for those months, with an appropriate offset. And then send it out another path for the other months with a different offset.

Alternatively, you could use the alt. start (right at bottom). I'm not sure how that works, because I dont use that part.

This is my fire fan, and I only want it to turn on in (southern) winter.

3 Likes

That's the direction I'm leaning in as well. I have 2 light sensors that automate the lights during the day but they are triggered on/off through the day. For the PM lights, I need them to turn on but not off, hence my approach of reading the lux setting at a point in time (say sunset - 60) but then not turning the lights on until the level hits the threshold.

1 Like

I just set mine up for the max pre-sunset adjustment and leave it there all year. Yes that means it turns on 30-60 minutes early some days. Don't care.

I do use my Weatherflow weather station brightness reading to turn on lights outside of the night light hours if it gets too dark outside.

3 Likes

I have a usb powered MS6 I am using outside in a clear weatherproof outlet box. I use that for turning exterior lights on and off. Be sure to leave a gap between lux on/off thresholds and also maybe a timeout before turning off otherwise on partly sunny days you can get some unnecessary on/off cycling..

1 Like

I like to do rolling averages/filters for outlier rejection. Can easily do that with a function node or the "smooth" node (using a low pass filter or mean). The "smooth" node is super handy for a number of things, actually.

2 Likes

I do exactly this for the interior lights during the day and have a gap of 10 lux that seems to work well for my use case.

You find 10 lux is enough? 10 lux is almost nothing... I would have thought that would have been too small, and lead to a lot of false positive/negative.

I just looked at my house data, and in my house the brightness fluctuates a lot more than 10 lux about 100x a day (window blinds are always open during day).

This is interesting. Can you share a flow please? I have 2 minute timeouts for my outside lux, and it does flick on and off too much.

I think it's the way my sensors are reporting or it could be that my sensors are indoors. I have my range for indoor lamps set to "on" if lux<20 and "off" if >30 and that seems to work. I have 2 sensors (Aeotec MS6 and a Xiaomi) and both work fine within that range. Light readings are one of the attributes that I am not logging, so I can't say for certain what the reporting range is, but when I was setting up the initial logic, I rarely saw reading > 100

1 Like

Must be, either that or they don't really report "lux" as 30 lux is super dark (~3 candles)... :slight_smile: A "normal" room in my house is almost 1000 - that was an exaggeration 650 lux, but I do like my rooms bright.

I haven't used an aeotec ms6 for lux in a long time (the ones I have are in my drawer of devices I hate). To be fair, they work fine for a lot of things, just not what I need - battery life sux, motion is too slow, etc.

In the end though if it works - it works. My biggest challenge with using interior lux is always placement of the sensor so it doesn't get blocked/covered at some point (cleaning people, holiday decorations, can't be in a shadow, etc).

1 Like

Sent you a PM.

I was curious, so I tried a lux meter that I have on my phone and the readings are close. It must be the way the light is coming in (it's not direct sun). When I pointed my phone app directly at the sun, the readings shot up to 11K.

Direct sun is ~130K lux though. A lot of sensors made for interior use top out at 10-15K, so it may be a sensor limitation.

People don't know/appreciate how BAD many lux sensors really are...

2 Likes

I guess in some ways it doesn't really matter as long as there is some sort of scale you can work with..High accuracy for my simple purposes (external/internal lights) is not super important. I guess if you were matching light levels and bulb/dimmer levels maybe.

1 Like