Ah… I deleted the /config/node-red folder as well as the /share/node-red. I realise the share one is from notoriousBDG version. Post corrected.
Projects feature popup now successfully disabled. 
In some of the other add ons of Node Red there is a timestamp node which makes it possible to trigger the flow manually when testing. That is missing here, but is there another node that does the same?
I also see this same problem. Projects were added in 0.18 and it uses git, with optional remotes, for version control built directly into node-red.
It would use SSH keys from here: /config/node-red/projects/.sshkeys/
But as mentioned it cannot generate them - probably as ssh-keygen is not in this container.
Also when you try to connect to the git remote from the history tab it cannot - probably no git.
Are you looking for the Inject node? That allows you to inject timestamps etc.
Ahh great, thanks - just what I was missing
The add-on allows for installation of additional packages… so you can add anything you like, including ssh-keygen…
Personally, I would use the SSH add-on to do those kind of things.
Release v0.3.0
Fixed
- Fixes Hadolint warning
Changed
- Upgrades home-assistant node to Spartan-II-117 fork
- Upgrades node-red-contrib-time-range-switch to 0.6.0 (#13)
- Disables the projects feature by default on new installs
- Upgrades base image to v2.0.1
- Upgrades nodejs to 8.11.3-r1
- Upgrades git to 2.18.0-r0
- GitLab CI now using the latest Hadolint
Removed
- Removes node-red-contrib-join in favor of the built-in one (#12)
Notes
In case you are running into issue with the current state nodes after upgrade; Open each current state node, delete the last character of the entity_id (so the dropdown appears with the suggestion), hit return, and then save.
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?
This is unchanged for existing users. So nothing to worry about in your case.
Nicely Done yet again. 
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?
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”}]
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.
Release v0.3.1
Changed
- Upgrades node-red-contrib-home-assistant (Spartan-II-117) to v0.3.3
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?
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).
so if we want to get state of entity_id ,we must replace payload with payload.state ?
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
6 Likes
THATS What happened. All my automations started breaking. Different status values started coming through and all my checks stopped working.
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.