Yup. @dan.t fixed that within a few hours.
I started with Tonesto's original (ported) Homebridge and that worked but had plenty of issues. When Dan.T rebuilt it into the MakerAPI version, I encouraged him to also create the HubConnect version. That's the one I've been using ever since and I'm sad to say that it is SOOOO stable, I never get to chat with @dan.t anymore
In IOS15, this is back working again and I can see split tiles and combine tiles as it works like a charm now. So I would say it was an IOS14 thing.
I'm having a strange problem with Homebridge/MakerAPI. The homebridge is not receiving POST events because it's setting it's own POST url incorrectly. The IP address it uses is correct, but it sets the port incorrectly. The end effect is that changes which aren't made in homekit aren't reflected in homekit.
I turned on all logging to find this problem, and I see this:
Homebridge Logs:
[Hubitat (C7-MakerAPI) hhm:0.4.15] Setting MakerAPI post URL to http://172.16.0.25:20011/event at http://172.16.0.5/apps/api/15/
[Hubitat (C7-MakerAPI) hhm:0.4.15] homebridge-hubitat-makerapi server listening on 20011
[Hubitat (C7-MakerAPI) hhm:0.4.15] MakerAPI postURL successfully activated
Hubitat MakerAPI Instance Logs:
app:15 debug url=http://172.16.0.25:20010/event
app:15 debug setPostURL called
The MakerAPI instance is setting the Post URL incorrectly, off by one. In this case the homebridge plugin started it's server on 20011 and asked the server to set the post URL to 20010. I'm a bit flabbergasted by the whole situation. Any suggestions or advice appreciated.
Are the hombridge config and the maker API, configured to use the same port?
When homebridge-maker-api starts up, it fires an api call to http://<hubitat.local.address>/apps/api/14/postURL/[URL]
which automatically configures the post back. That's what I take the "MakerAPI postURL successfully activated" log message to mean.
On the MakerAPI side, setPostURL called
is the message indicating that hubitat-side endpoint has been hit, and url=http://...
is the url that it received.
The problem I'm trying to illustrate here is that the nodejs plugin is automatically (and repeatedly) attempting to configure the server to hit port 20011
but the makerAPI is actually configuring it for 20010
. This is where the mismatch is coming from.
You might be missing a bracket "}" somewhere or an extra/missing comma.
EDiT: not necessarily in the screencap you showed. Usually at the end is where it happens.
Line 90 seems redundant and incomplete.
I used the initial config creator, and I checked for brackets...
{
"bridge": {
"name": "Homebridge",
"username": "B5:BB:16:6E:1D:80",
"port": 51936,
"pin": "556-91-494"
},
"mdns": {
"interface": "192.168.1.53"
},
"platforms": [
{
"platform": "Hubitat-MakerAPI",
"name": "Hubitat MakerAPI",
"app_url": "http://192.168.1.52/apps/api/258/",
"access_token": "50d63c89-669f-42d0-8d70-faf075e37da3",
"local_ip": "192.168.1.53",
"local_port": 20010,
"mode_switches": true,
"hsm": true,
"debug": false,
"logFile": {
"enabled": true,
"path": "",
"file": "",
"compress": true,
"keep": 5,
"size": "10m"
}
}
],
"platform": "Hubitat-MakerAPI"
}
Is that from the generator or directly from the HB settings?
I recreated again and this is directly from the generator. Same error
{
"bridge": {
"name": "Homebridge",
"username": "54:F9:77:D9:D6:AA",
"port": 51936,
"pin": "872-82-759"
},
"mdns": {
"interface": "192.168.1.53"
},
"platforms": [
{
"platform": "Hubitat-MakerAPI",
"name": "Hubitat MakerAPI",
"app_url": "http://192.168.1.52/apps/api/258",
"access_token": "50d63c89-669f-42d0-8d70-faf075e37da3",
"local_ip": "192.168.1.53",
"local_port": 20010,
"mode_switches": true,
"hsm": true,
"debug": false,
"logFile": {
"enabled": true,
"path": "",
"file": "",
"compress": true,
"keep": 5,
"size": "10m"
}
}
]
}
That's the only URL in the config and that number at the end (258) must match the MakerAPI instance. Verify that you're copying the URL from MakerAPI correctly
I just installed it and am getting the same thing you are... I seem to remember this happening before but can't recall what the issue was... mmm
Okay - get rid of the "bridge" and "mdns" entries from the config.
Note: you can probably leave the mdns entry in but in my zeal I removed both.
This ended up working... Thanks @erktrek and @csteele !
{
"platform": "Hubitat-MakerAPI",
"name": "Hubitat MakerAPI",
"app_url": "http://192.168.1.52/apps/api/258",
"access_token": "50d63c89-669f-42d0-8d70-faf075e37da3",
"local_ip": "192.168.1.53",
"local_port": 20010,
"mode_switches": true,
"hsm": true,
"debug": false,
"logFile": {
"enabled": true,
"path": "",
"file": "",
"compress": true,
"keep": 5,
"size": "10m"
}
}
This seems to have broken on me with a recent update. I have several instances of homebridge running and all the ones that use this plug-in are crashing to the point that the interface won’t load. I’m running the oznu homebridge docker image.
I’m getting the following error and the web interface won’t load:
npm WARN Could not resolve dependency:
npm WARN peer eslint@"^6.0.0 || ^7.0.0 || ^8.0.0" from @typescript-eslint/eslint-plugin@5.28.0
npm WARN node_modules/.pnpm/homebridge-config-ui-x@4.47.0/node_modules/homebridge-config-ui-x/node_modules/@typescript-eslint/eslint-plugin
npm WARN dev @typescript-eslint/eslint-plugin@"^5.18.0" from homebridge-config-ui-x@4.47.0
npm WARN node_modules/.pnpm/homebridge-config-ui-x@4.47.0/node_modules/homebridge-config-ui-x
npm WARN ERESOLVE overriding peer dependency
any ideas?
thanks
I'm still on Homebridge UI 4.46 on a RPi4 (though there is a prompt for an upgrade) and that is working fine. Anyone else having an issue with 4.47?
My philosophy has been that unless there's a new must-have homebridge or homebridge-ui-x feature, I leave them alone. My homebridge installation is on version 1.2.5, and homebridge-ui-x is at 4.4.3.
Same with node-red.