Community Hass.io Add-on: Node-RED

hassio-repository
hassio-addon
Tags: #<Tag:0x00007f059530cdb0> #<Tag:0x00007f059530cc70>

#50

Fantastic work on this add-on @frenck, thank you. With 0.3.0, what happens to existing installs that already use projects? Do we need to add something to our settings to retain projects support?


#51

This is unchanged for existing users. So nothing to worry about in your case.


#52

Nicely Done yet again. :+1:


#53

Very nice, thanks.
I have updated and restartet the plugin, but node-red-contrib-join is still active. What do i have to do to remove it from the existing installation?


#54

On some of my automations I check with an “Anyone Home” virtual presence sensor. For instance, don’t turn on the evening lights if no one is home. After this update I’m getting this error which is preventing it from running:

7/16/2018, 7:56:27 AMnode: Anyone Home?
msg : error
“TypeError: Cannot read property ‘indexOf’ of undefined”

[{“id”:“53427ef8.5c8d3”,“type”:“bigtimer”,“z”:“f6dcdaf5.1dd23”,“outtopic”:"",“outpayload1”:“on”,“outpayload2”:“off”,“name”:“Sunset”,“lat”:"…",“lon”:"…",“starttime”:“5004”,“endtime”:“1380”,“startoff”:"-30",“endoff”:0,“offs”:0,“outtext1”:"",“outtext2”:"",“timeout”:1440,“sun”:true,“mon”:true,“tue”:true,“wed”:true,“thu”:true,“fri”:true,“sat”:true,“jan”:true,“feb”:true,“mar”:true,“apr”:true,“may”:true,“jun”:true,“jul”:true,“aug”:true,“sep”:true,“oct”:true,“nov”:true,“dec”:true,“day1”:0,“month1”:0,“day2”:0,“month2”:0,“day3”:0,“month3”:0,“day4”:0,“month4”:0,“day5”:0,“month5”:0,“d1”:0,“w1”:0,“d2”:0,“w2”:0,“d3”:0,“w3”:0,“d4”:0,“w4”:0,“d5”:0,“w5”:0,“suspend”:false,“random”:false,“repeat”:false,“atstart”:false,“odd”:false,“even”:false,“x”:80,“y”:840,“wires”:[[“f2aa0483.0a2908”],[],[]]},{“id”:“8a76e315.138718”,“type”:“api-call-service”,“z”:“f6dcdaf5.1dd23”,“name”:“Main Lights On”,“server”:“5054d49.71a7cac”,“service_domain”:“homeassistant”,“service”:“turn_on”,“data”:"{ “entity_id”: “group.main_lights” }",“mergecontext”:"",“x”:700,“y”:920,“wires”:[[]]},{“id”:“f2aa0483.0a2908”,“type”:“switch”,“z”:“f6dcdaf5.1dd23”,“name”:“Switch”,“property”:“payload”,“propertyType”:“msg”,“rules”:[{“t”:“eq”,“v”:“on”,“vt”:“str”},{“t”:“eq”,“v”:“off”,“vt”:“str”}],“checkall”:“true”,“repair”:false,“outputs”:2,“x”:270,“y”:900,“wires”:[[“2e3e58ea.5726a8”],[]]},{“id”:“dfbe557b.859f5”,“type”:“api-call-service”,“z”:“f6dcdaf5.1dd23”,“name”:“Dimming Lamps On”,“server”:“5054d49.71a7cac”,“service_domain”:“homeassistant”,“service”:“turn_on”,“data”:"{ “entity_id”: “group.dimming_lamps”, “brightness_pct”: “100” }",“mergecontext”:"",“x”:880,“y”:860,“wires”:[[]]},{“id”:“ab61609a.a20f48”,“type”:“stoptimer”,“z”:“f6dcdaf5.1dd23”,“duration”:“3”,“units”:“Minute”,“payloadtype”:“num”,“payloadval”:“0”,“name”:“3 min”,“x”:670,“y”:860,“wires”:[[“dfbe557b.859f5”],[]]},{“id”:“2e3e58ea.5726a8”,“type”:“api-current-state”,“z”:“f6dcdaf5.1dd23”,“name”:“Anyone Home?”,“server”:“5054d49.71a7cac”,“halt_if”:“off”,“override_topic”:true,“override_payload”:true,“entity_id”:“binary_sensor.anyone_home”,“x”:460,“y”:900,“wires”:[[“8a76e315.138718”,“ab61609a.a20f48”]]},{“id”:“5054d49.71a7cac”,“type”:“server”,“z”:"",“name”:“Home Assistant”,“url”:“https://8123”,“pass”}]


#55

This update broke some of my more complex presence detection automations.
Even after updating all the current state nodes (mentioned in the release notes), something changed with how the current state nodes pass data further down the flow.


#56

:tada: Release v0.3.1

Full Changelog

Changed

  • Upgrades node-red-contrib-home-assistant (Spartan-II-117) to v0.3.3

#57

I’m also having the same issue. some nodes are simply not getting the data from hassio

Hassio 0.73.2
Node-red v0.3.1

After deleting and adding some of device_tracker nodes I noticed that state is not longer in payload, now its in payload.state

Some nodes can be fixed with deleting the last letter “trick” but some others you have to completely recreate them.

Is the new payload.state going to be the new way of passing the state? or this is a bug?


#58

According to the source code in the Spartan fork, this has changed.
The same change is also pending at the original repository, nevertheless, the original repository is a little “dead” (hence the fork by Spartan).


#59

so if we want to get state of entity_id ,we must replace payload with payload.state ?


#60

Ok, so up straight in here:

I regret the decision of switching to the Spartan-II-117 fork.

Let me explain how and why.

On Reddit, a group of enthusiasts recommended the fork and I do see value in the code living inside the fork. Nevertheless, as a couple of days went by, multiple issues start occurring, such as the ones listed above in this topic.

Secondly, I’ve watched the development happen and start noticing things that were not usual. Things like: Weird ways of Git and release handling, but also the quality of the code; like weird indenting and stuff. (Which is not perse bad, but an indicator for sure).

So currently, the fork contains additional code over the original and are all created by 2 users.

One of them I spoke to on Discord, and he told me he hoped his code worked since he copied and pasted some stuff. I quote:

“I am not a code lol. It was mostly copied and paste though”

The other person just responded on an issue created on his GitHub fork:

This does not feel good… not at all.

So my current thought, switching back to the original codebase (by default) and I’m going to look into providing additional instructions on installing the Spartan fork (if you still dare).

For me, this is a failure from my side. I should have been more careful and give the things a second thought. I’m truly sorry for what happened and I really hope I did not give you a hard time.

…/Frenck


#61

THATS What happened. All my automations started breaking. Different status values started coming through and all my checks stopped working.


#62

And thanks for striving to make things better. I would have switched over to that fork myself, but didn’t only because i didn’t have an easy way. The downside is the auto nature of my node-red hass-io updates means introducing major changes is a really tricky thing to manage.


#63

I wanted to say, “You are welcome”. But I think an apology from my side is more appropriate at this time.

As for any update on any platform. My personal grind, is “downgrading” add-ons seems impossible (but it is possible via the CLI).

Nevertheless, hold on, I already have the code editors open…


#64

:tada: Release v0.4.0

See my posts above for the exact reasoning behind this release.

Again, my apologies. :heart:

Full Changelog

Changed

  • Downgrades the add-on back to the original node-red-contrib-home-assistant
  • Upgrades node-red-node-suncalc to version 0.0.11 (#14)

Manually using the Spartan-II-117 fork

In case you still like to use the Spartan-II-117 fork, simply add the following NPM package to the addon configuration like so:

  "npm_packages": [
    "git+https://github.com/Spartan-II-117/node-red-contrib-home-assistant#v0.3.3"
  ],

#65

Hi Frenck,

Thanks for your commitment, I also felt strange when saw those comments.

Although, it seems that the Spartan fork is getting some momentum, there was a PR today. we could keep an eye and see how that develops.


#66

First off, I’d like to say that I am so sorry for the confusion and chaos my fork caused for people, I have released a new version which the api-current-state has been tested to be backwards compatible with AYapejian’s version, but still includes the status indicators from my fork.

This fork was for my own personal use before it was discovered by a Redditor about a week ago, since then i have been trying to find the time to get it up to standards.

I hope some of you find it useful!


#67

@Spartan.II.117
Your fork is great and new contributions are always welcome. Please don’t be discouraged by the first positive and then negative publicity. There are many of us really hoping for a stable, yet actively developed alternative to AYapejian’s version (which, though great, is a bit neglected now).

Backward compatibility would be highly appreciated where possible, as updating numerous flows from ages ago, is a pretty painful task and negatively impacts WAF due to sudden automation failures throughout the house :sweat_smile:

@frenck Thanks a ton for providing the option to still use other forks within the add-on!


#68

@Spartan.II.117 and @frenck thanks for being two stand up individuals who at the end of the day just want to make things the best for all the users and not let any crazy egos get in the way. Its situations like this that definitely make me enjoy and proud to be a part of the HomeAssistant community here! Well done gentlemen!


#69

I would also like to chime in and offer an apology of sorts :frowning: I just wanted to share the fork on Reddit, I didn’t anticipate the amount of traction the post got!

Thanks to the @Spartan.II.117 and @frenck, sorry for everyone’s lost time, and I hope no-one’s WAF was permanently affected.

I am still using the fork as I think it’s great. I’ve just modified msg.payload to msg.payload.state where necessary. Just waiting out the whole current-state node thing until it’s completely finalised.