Node-red-contrib-homekit-bridged: some changes are only applied when restarting node-red, not when re-deploying

[oliverrahner]

Those issues are related to KhaosT/HAP-NodeJS#580.

I don't know of a clean way to solve this, yet.

Things not working are:

• name changes for service nodes are not always published
• removing service nodes does not remove them from the Home app
• state changes "into" the homekit node are not sent out or received by the Home app anymore

All of those issues are always fixed after restarting node-red, so they are "only" a pain when changing something, not during actual usage.

[schford]

I too have this issue of state change into the homekit node - which is solved by restarting node red.

[ipa64]

Hi nothing new about this annoying bug ?

[YinHangCode]

I also have the same problem.

[Hirschenberger-S]

Same here

[oliverrahner]

As KhaosT/HAP-NodeJS#580 is now resolved, I'll start working on a possible fix when I have some spare time in the next days (or maybe weeks :-/)

[Shaquu]

For the record. I have implemented change made in KhaosT/HAP-NodeJS#580

[radokristof]

So don’t need to restart nodered? Which version includes this?
Is this true for new Device in HomeKit as well? It will show up after re-deployment?

[Shaquu]

@radokristof I have implemented change but I think that doesn't help.
I have some ideas what's going on though.

[oliverrahner]

@Shaquu when I mentioned KhaosT/HAP-NodeJS#580 had been implemented, I hoped that KhaosT would have done it in a way that solves the issues that he mentioned (https://github.com/KhaosT/HAP-NodeJS/pull/580#issuecomment-386829810). Unfortunately, that was not the case. The change that he made was the same that I had in place as a workaround, which didn't work :(

[Shaquu]

@oliverrahner I know I know. Unfortunately I still cannot find the problem.

[oliverrahner]

Just wanted to clarify, so you don't repeat all the mistakes I made ;)

[Shaquu]

I have an idea which make unpublish() useless.
I think I have to change this:

this.on("close", function (removed, done) {
            if (removed) {
                // This node has been deleted
                bridge.destroy();
            } else {
                // This node is being restarted
                bridge.unpublish();
                bridge = null;
                this.published = false;
            }
            done();
        });

to this:

this.on("close", function (removed, done) {
            bridge.destroy();
            bridge = null;
            self.published = false;
            done();
        });

Why? Since we "create" new Bridge every time then we should destroy connection every time.

I am pretty sure it will solve a lot...
I will try today evening.

[Shaquu]

Unpublished (unpublish()) Bridge with working server (not destroyed) could cause #22

I twisted something...

[iRonin]

+1 windows stuck in constant opening/closing state…

[Shaquu]

@iRonin thanks for feedback. I am still working on it in my free time.

[877dev]

Same issue here, you only have to move the node and re-deploy and the output stops "outputting".
Works fine after re-starting node red (running on Pi3).

Thanks guys for the node and hope you find the bug! :)

[Appelg]

Is it possible to at least document this someplace (maybe in the INFO tab for the affected sensors?). As a new user, I just spent a couple of hours trying to figure out why my temp-sensors stopped updating :P

[radokristof]

All sensors/accesories are affected. Will look into it.

Sent from my iPhone

On 2019. May 26., at 16:29, Appelg [e-mail] wrote:

Is it possible to at least document this someplace (maybe in the INFO tab for the affected sensors?). As a new user, I just spent a couple of hours trying to figure out why my temp-sensors stopped updating :P

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Appelg]

I don't know if this is obvious, but a friend of mine told me that if you choose the deploy-mode "Modified Nodes", this bug won't trigger. I just tested it and it works, so as long as you just are tweaking node settings, you don't need to restart node-red every single deploy :)

[877dev]

@Appelg that’s a great tip, I had not thought of that.

I wonder if there’s any progress on a bug fix? I’d be happy to test.

[radokristof]

@Appelg thanks however I knew that. But this will only help if you mess around with other nodes. As soon as you change something in one of your HomeKit nodes, it won't get updated (it gets updated 1 time, but not for the second time, you need to restart Node-RED again).

[Shaquu]

184 got merged into dev branch

Please test fixes npm i [email protected]
Remember that dev version has latest patches but can be unstable and without backward compatibility.
Current dev is not compatible with latest master release - you will have to re-add all accessories in home.app.

[radokristof]

@Shaquu I need to re-add my accessories after update?

[Shaquu]

@radokristof yes, unfortunately dev (and next release) is not backward compatible.

Changelog here (should be complete but you know...)

[Shaquu]

So how do you feel. Can it be closed now after 1.0.X release?

[crxporter]

Coming up on the 2 year mark on this one!

As far as I’ve seen it’s done, I couldn’t make the redeploy bug come up on the dev branch but I haven’t actually moved to the 1 release.

[Shaquu]

@crxporter please tell me how could I make it more comfortable for you to upgrade to latest release.

[crxporter]

@Shaquu I’m in the middle of replacing my Insteon hardware with zwave. My approach for a while was “don’t poke the Insteon bear” so I haven’t done much. Over the next couple of days I’ll be shutting down my old setup and building fresh with 1.0.

Might cut house power this afternoon and replace a bunch of switches...

[crxporter]

Alright I did one small step. Sprinklers are 100% updated to 1.0.3 (and new node red). My other pi's will be more difficult projects.

Redeploy bug is dead, upgrade went great.

[crxporter]

@Shaquu let's close it!

This is a huge one to close. Congratulations, sir and excellent work!