mDNS hostnames stopped working #29
Comments
|
Obviously this may not be the fault of the plugin since other intermediary things updated too. Just figured I’d ask in case y’all can help! My homebridge has been running with the Avahi advertiser for some time now. I did previously use Ciao. |
|
I don't have any good ideas. What happens if you revert to the version of the plugin you were running before you updated to v0.5.4? You're running more recent versions of homebridge and node than I am so I'll update them here and see what happens. For what it's worth I'm running homebridge on macOS 10.14.6 with Bonjour HAP and use the .local in the config file (Big Fan is the fan name, BigFan.local is its mDNS(?) name. |
|
I've installed homebridge on macOS Ventura with the same versions you showed. In one of the six restarts it threw the ENOTFOUND error but after 3 retries (the backoff timing is very primitive) it reconnected.
I don't know why it got ENOTFOUND, why it didn't get ENOTFOUND every time, nor why the 3rd retry was successful. I'll keep playing with it. |
|
Interesting! Mine seems to always ENOTFOUND. I will try older plugin version later today. |
|
Well, went to downgrade to v0.5.3 to try it out, but now the issue is not recurring, even with exactly the setup (and versions) cited above. Odd. |
|
I did an experiment to see if it's a purely a node.js issue. On machine A I ran a listener and on machine B running node v18.17.0 connected to that listener with a node client script. When the script tried to connect to machine A using its mDNS name it failed with EHOSTUNREACH. When I used its IP address it succeeded. If I flipped roles, running the listener on machine B and Machine A running node V16.16.0 connecting to that listener, it successfully connected using the mDNS name of machine B. When I was looking into ENOTFOUND problems with node.js, I came across discussions touching on addressing IPV4 vs IPV6. And my experiment seems to indicate an IPV6 angle: I don't why the error was EHOSTUNREACH rather than ENOTFOUND. My next experiment (for another day) will be to try to specify IPV4 in the node connect() call. [edited to add] - downgrading node to v16.16.0 on machine B allows the client script to successfully connect to the mDNS name of machine . |
That's seems to be the nature of the problem. |
|
Ok long story short, I made a mistake and caused cached accessories to duplicate, so I wasn't testing what I thought I was testing above. I'm back to ENOTFOUND with v0.5.4, and v0.5.3. I think it'll be less easy for me to revert nodejs version but I'd totally believe that could be an issue. |
|
I see now that there are more-official homebridge packages for Ubuntu. Maybe I'll look into switching to those, I wonder which nodejs they're bundling. |
|
I added an option to the node.js client script to specify IPV4 and the test succeeded with node v18.17.0 where it previously failed with that version. There's still the question why you (and I at least once) are seeing ENOTFOUND while my script was generating EHOSTUNREACH but I'm not going to worry about that for the time being. It seems that the option to specify family (IPV4 or IPV6) in node is different for v16.x and v18.x although the documentation indicates it's the same. But when I run it on v16.x with the v18.x format (the string 'ipv4' vs the number 4) it blows up and tells me to use a number type. So it looks like I need to a) verify the documentation is incorrect and then b) detect the version of node.js in the plugin, followed by c) putting out a new beta since only you so far can reliably reproduce this issue. [edited to add] the documentation is not incorrect. I was misreading it. |
|
Ok, downgrading nodejs fixed this. Pretty sure that was the issue. Thanks for the tip @oogje ! |
|
Also whenever you have a new beta I'll know I can try on v18.17.0 specifically. Seems very consistent that it functions ok with v18.16.1 and always fails with v18.17.0. |
|
If and when you're prepared for the real possibility you might have to back out of it, the new beta is: |
|
I tried Trying to debug this is wild. It only gives I briefly tried turning on Homebridge debug mode, but other plugins are spouting so much stuff that I can’t even catch the bigassfans plugin startup messages before the whole scrollback is filled. Once I install and run homebridge with |
|
I'm sorry you had to go through that. If I understand correctly you're now either using I'm not surprised So if you're good where you are now, I'll see if I can get answers about the ENOTFOUND business from somewhere. By the way, I'm using Bonjour HAP and still get the rare |
|
It’s not hosed-hosed! It’s just odd that it requires a full reboot to get back to working. In my case it seems quite consistent — I can still use mDNS hostnames with Yes after all this it seems like a better use of my time would be to configure consistent IPs for my fans in my DHCP and just use IPs. But I do enjoy fiddling. 😆 |
|
I think
|
|
If you want to fiddle I'm all for it. I understand you're running Homebridge on a linux machine, but are you by any chance using a Mac otherwise? |
|
Yes we have several MacBooks Air and Pro. I’m ssh’ing from one over to the Ubuntu Intel machine when I’m upgrading / downgrading its Node and Homebridge plugins. In case this is a weird me-thing with my network / mDNS:
|
|
Frankly, the network beast is magical to me. I just try to appease it. My hope is to get If you can locate the log file then you can pick out only the fan plugin's messages with:
I'm my case:
The next step would be to add some debugging directives to your config.json for each of your fans to dump all the messages your fans send to the plugin. I should be able to use those logs to simulate your fans on my machine. The debugging addition to each fan's config is: don't forget to insert a comma before this line if appending it after You can do this with I believe you already know how to start homebridge with "-D". Having done that, restart, wait a few minutes, grep the fan messages out of the log file and either mail them to me at Then we'll see what's what. |
|
Sent |
|
I got your logs, thanks. Here's hoping there's a smoking gun in there. In any event, having these is very helpful in general so I can simulate different setups. |
|
From the logs it seems the plugin thinks the Master Bedroom Overhead Fan has a downlight and the other two fans have no lights at all. Is that how your fans are equipped? |
|
That is correct. |
|
That's a relief. In the meantime I've identified the problem. It has to do with (presumably) my misinterpreting your bedroom fan's schedule. Maybe the others also but this is the first one I tripped over. I'm still looking into it to see exactly where it goes south. |
addresses issue #29, schedule parsing freakout
|
I'm hopeful
and |
|
So far so good with Edit: No luck with mDNS hostnames with
This seems very likely why I had to reboot. I’m using child bridges, but sounds like |
|
Am glad we resolved the issue with beta3. Thanks. Can you try to run this test script under |
Hmm, just testing a hunch here... What if NodeJS 18.17.0, or something between that and my Linux machine's Avahi/mDNS/whatever, no longer likes |
|
That sounds like a solid hunch. |
|
Doing some googling. Using Even Avahi on this Ubuntu can't be consistent with itself wrt the Big Ass Fans hostnames: At this point I've set fixed IPs for my fans anyway and am perfectly happy just letting this all go. It was a fun curiosity. |
|
I don't know where that -xx:xx:xx.local name comes from. I just have <fan name[without white space, punctuation, etc].local on macOS. Using the last three octets of the MAC address format isn't pingable here. Yes, it was fun. I learned a bit. Not enough, but a bit. |
|
Yeah weirdly |
|
Maybe it's tied to the model. I have an |
|
Seems very likely. Newer firmware, no longer setting out-of-spec mDNS names. Just funny they didn't bump that part of the software with the big update to move over to the new protocol and app. |
|
As always, thanks for all you do for this plugin. Thanks for coming along on my probably-unnecessary adventures. And I think(?) we accidentally caught what would’ve been a real bug with |
|
As always, my pleasure. And yes, tripping over the schedule bug was fortunate indeed. |
|
Just to document in case people come across this thread: |
Describe The Bug:
I’ve been successfully using the
Entryway-XX:XX:XX.localtype format since, well, April 23 2022 presumably (#6).Today some combination of updates seems to have made that stop working. I repeatedly get:
Logs:
Plugin Config:
{ "fans": [ { "name": "Master Bedroom Overhead Fan", "ip": “MasterBedroom-XX:XX:XX.local", "mac": “XX:XX:XX:XX:XX:XX", "fanModel": "Haiku H/I Series", "showWhooshSwitch": false, "showFanAutoSwitch": false, "showLightAutoSwitch": false, "showDimToWarmSwitch": false, "showEcoModeSwitch": false, "disableDirectionControl": false }, { "name": "Cocktail Room Overhead Fan", "ip": “CocktailRoom-XX:XX:XX.local", "mac": "XX:XX:XX:XX:XX:XX", "fanModel": "Haiku H/I Series", "showWhooshSwitch": true, "showFanAutoSwitch": false, "showLightAutoSwitch": false, "showDimToWarmSwitch": false, "showEcoModeSwitch": false, "disableDirectionControl": false }, { "name": "Study Overhead Fan", "ip": “Study-XX:XX:XX.local", "mac": "XX:XX:XX:XX:XX:XX", "fanModel": "Haiku H/I Series", "showWhooshSwitch": true, "showFanAutoSwitch": false, "showLightAutoSwitch": false, "showDimToWarmSwitch": false, "showEcoModeSwitch": false, "disableDirectionControl": false } ], "_bridge": { "username": "XX:XX:XX:XX:XX:XX" }, "platform": "BigAssFans-i6" }Environment:
Things I tried:
CocktailRoom-XX:XX:XX.localand all the rest from the computer running Homebridge just fine.For now I’ve switched to resolved IP address, which works.
The text was updated successfully, but these errors were encountered: