You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[26/03/2023, 18:04:39] Registering platform 'homebridge-sma-home-manager.SMAHomeManager'
[26/03/2023, 18:04:39] [homebridge-sma-home-manager] Loaded homebridge-sma-home-manager v1.1.1 child bridge successfully
[26/03/2023, 18:04:39] Loaded 0 cached accessories from cachedAccessories.0EE7D444A20A.
/usr/local/lib/node_modules/homebridge-sma-home-manager/index.js:285
Object.keys(signalNames).forEach(id => {
^
TypeError: Cannot read properties of undefined (reading 'offGrid')
at /usr/local/lib/node_modules/homebridge-sma-home-manager/index.js:286:35
at Array.forEach (<anonymous>)
at SMAHomeManager.accessories (/usr/local/lib/node_modules/homebridge-sma-home-manager/index.js:285:28)
at /usr/local/lib/node_modules/homebridge/src/bridgeService.ts:534:24
at new Promise (<anonymous>)
at BridgeService.loadPlatformAccessories (/usr/local/lib/node_modules/homebridge/src/bridgeService.ts:528:12)
at ChildBridgeFork.startBridge (/usr/local/lib/node_modules/homebridge/src/childBridgeFork.ts:155:36)
[26/03/2023, 18:04:39] [homebridge-sma-home-manager] Child bridge process ended
[26/03/2023, 18:04:39] [homebridge-sma-home-manager] Process Ended. Code: 1, Signal: null
[26/03/2023, 18:04:46] [homebridge-sma-home-manager] Restarting Process...
Also does your plugin ever wait for the didFinishLaunching event? Im not sure if your plugin type needs to or not. But I wonder if this is the reason of the logging
[26/03/2023, 18:23:24] [homebridge-sma-home-manager] This plugin is taking long time to load and preventing Homebridge from starting. See https://homebridge.io/w/JtMGR for more info.
The support for homebridge-config-ui-x would never result in that sort of configuration as far as I can tell? 😅
The plugin will never launch unless both an SMA solar inverter is discovered (using mDNS/DNS-SD) and a SMA Home Manager (using a Speedwire multicast subscription, where this device is broadcasting a datagram every second) are found. You likely do not have either device on your network, which is why the plugin takes so long to launch: it keeps trying indefinitely. I'm happy to change that to a limited period of time of course. But: A) the logging should make it pretty clear, B) it's then absolutely pointless to run this plugin.
(Over here it typically takes a few seconds to discover the devices, connect, and then launch.)
Re (1) - there are still plenty of users who configure stuff directly with JSON, so we just need to make sure that any 'config issues' are caught properly by its plugin - to make sure that it does not send homebridge into a crash loop and therefore not stop any other plugin from functioning. homebridge-config-ui-x has made things so much easier for a lot of users, but please don't assume that every user will be using this.
Re (2) - okay 👍 - no action needed from you, thanks for explaining
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
We believe that you are facing the accessory-resetting option because you are not making use of the homebridge cache accessory feature that platform-based plugins should use.
I know I have mentioned the discord thing before, i would really like to help you get this plugin looking great, discord is basically like 'slack' but a homebridge community, and totally happy to have a 1:1 chat with you to explain about cached accessories.
I would find this much easier than trying to let it all out in one github post!!
A signup link is here https://discord.gg/kqNCe2D and once you have registered you can just find me and send me a DM my username is bwp91.
Why do this in real-time chat when none of us are likely to be online at the same time? And if we'd communicate async there, then how is it any better from discussing it here?
IOW: why not use this very GitHub issue? I'm used to seeing dozens or hundreds of comments on issues/tickets/PRs/MRs (I work on open source PHP software for my day job), because that results in linkable, searchable discussions that allow understanding why certain decisions were made years later.
That'd allow you to point to the discussion/guidance you'd provide here rather than having to do it all over again for somebody else.
We believe that you are facing the accessory-resetting option because you are not making use of the homebridge cache accessory feature that platform-based plugins should use.
Static platforms know which accessories they want to expose on start up. The set of accessories cannot change over the lifespan of the plugin.
That's a perfect fit for my use case! It is impossible for an additional PV inverter or energy manager to appear out of nowhere. IOW: there is no need for dynamic accessory discovery.
But you're now telling me that I should not expose an accessory that I do not know for certain will have a successful connection. AFAICT that implies that one should never use a static platform? If so, why is it in the official examples to this day?
At this point, it honestly feels rather arbitrary to not grant my plugin the "Verified" stamp. My plugin boots even when you do not have the necessary hardware, and it gives you actionable, precise feedback. Besides, the only reason it does not boot for you is because you don't have the hardware.
If I install an app on my smart phone that requires certain hardware to be connected, you also expect it to launch and inform you, right? Isn't this similar to that?
I'm definitely willing to make the changes mentioned in #527 (comment).
But refactoring from static to dynamic platform is wrong AFAICT. I tried to follow the prescribed best practices when I refactored the unmaintained & unreliable https://github.com/codyc1515/homebridge-sma-inverter project (but thankfully somebody built that! Otherwise getting started would've been much harder!) into something that works reliably.
The examples still list it, so surely it still is a recommended approach?
I'd really like that "Verified" badge to encourage more people to save energy in their home. I can't believe I've been trying this for >6 months at this point. 😞
As a fellow open source maintainer, I applaud your relentless attention to the end user experience! 😊 👏 But AFAICT this plugin is already more reliable than most plugins I've tried. With more precise guidance. With clearer docs. With actual responses from the maintainer. So … why is it not good enough?
Why do this in real-time chat when none of us are likely to be online at the same time? And if we'd communicate async there, then how is it any better from discussing it here?
IOW: why not use this very GitHub issue? I'm used to seeing dozens or hundreds of comments on issues/tickets/PRs/MRs (I work on open source PHP software for my day job), because that results in linkable, searchable discussions that allow understanding why certain decisions were made years later.
That'd allow you to point to the discussion/guidance you'd provide here rather than having to do it all over again for somebody else.
Understood. We are trying to urge developers to always use dynamic-platform-type plugins. About a month ago I updated the homebridge wiki to just have links to the dynamic-platform type template as well as the camera-plugin template. https://github.com/homebridge/homebridge/wiki
It's a gradual process. And whilst I took the links away from the homebridge-examples plugin templates, I didn't want to delete all the repos under this name right now.
Sorry it has been a lot of to-ing and fro-ing, but I really am taking into account now what you have said in your last reply, and this verification process in this case I totally understand has been very frustrating for you. This really was never my intention 😅
let me re-run the checks and have another ponder...
If for any reason in the future you can no longer maintain your plugin, please consider transferring it to our unmaintained plugins repo. We can take ownership until another willing developer comes along.
Don't forget to join the official Homebridge Discord server, where plugin developers can get tips and advice from other developers and the Homebridge project team in the #plugin-development channel!
Activity
github-actions commentedon Mar 26, 2023
✅ Pre-checks completed successfully.
bwp91 commentedon Mar 26, 2023
A basic config of
sends Homebridge into a crash loop:
Also does your plugin ever wait for the
didFinishLaunchingevent? Im not sure if your plugin type needs to or not. But I wonder if this is the reason of the loggingand the icon never turning to green?
wimleers commentedon Mar 28, 2023
@bwp91
homebridge-config-ui-xwould never result in that sort of configuration as far as I can tell? 😅(Over here it typically takes a few seconds to discover the devices, connect, and then launch.)
bwp91 commentedon Apr 1, 2023
Hi @wimleers
Re (1) - there are still plenty of users who configure stuff directly with JSON, so we just need to make sure that any 'config issues' are caught properly by its plugin - to make sure that it does not send homebridge into a crash loop and therefore not stop any other plugin from functioning.
homebridge-config-ui-xhas made things so much easier for a lot of users, but please don't assume that every user will be using this.Re (2) - okay 👍 - no action needed from you, thanks for explaining
wimleers commentedon Apr 9, 2023
Makes sense, will address that!
bwp91 commentedon Apr 12, 2023
Great! Once ready, please reply on here with a comment just saying
/checkand we can try again 👍github-actions commentedon May 13, 2023
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
wimleers commentedon May 16, 2023
I will follow up on this in the coming week.
71 remaining items
bwp91 commentedon Sep 22, 2023
Before you start making these changes let me have a discussion with some other maintainers.
I do see your side of this too 😃
bwp91 commentedon Sep 28, 2023
Hi @wimleers
We believe that you are facing the accessory-resetting option because you are not making use of the homebridge cache accessory feature that platform-based plugins should use.
I will reply again with more info...
bwp91 commentedon Sep 30, 2023
I know I have mentioned the discord thing before, i would really like to help you get this plugin looking great, discord is basically like 'slack' but a homebridge community, and totally happy to have a 1:1 chat with you to explain about cached accessories.
I would find this much easier than trying to let it all out in one github post!!
A signup link is here https://discord.gg/kqNCe2D and once you have registered you can just find me and send me a DM my username is
bwp91.wimleers commentedon Oct 9, 2023
Why do this in real-time chat when none of us are likely to be online at the same time? And if we'd communicate async there, then how is it any better from discussing it here?
IOW: why not use this very GitHub issue? I'm used to seeing dozens or hundreds of comments on issues/tickets/PRs/MRs (I work on open source PHP software for my day job), because that results in linkable, searchable discussions that allow understanding why certain decisions were made years later.
That'd allow you to point to the discussion/guidance you'd provide here rather than having to do it all over again for somebody else.
No, I'm facing that because I followed the developer docs at https://github.com/homebridge/homebridge-examples#platform-plugins, which says:
That's a perfect fit for my use case! It is impossible for an additional PV inverter or energy manager to appear out of nowhere. IOW: there is no need for dynamic accessory discovery.
But you're now telling me that I should not expose an accessory that I do not know for certain will have a successful connection. AFAICT that implies that one should never use a static platform? If so, why is it in the official examples to this day?
At this point, it honestly feels rather arbitrary to not grant my plugin the "Verified" stamp. My plugin boots even when you do not have the necessary hardware, and it gives you actionable, precise feedback. Besides, the only reason it does not boot for you is because you don't have the hardware.
If I install an app on my smart phone that requires certain hardware to be connected, you also expect it to launch and inform you, right? Isn't this similar to that?
That's far better than most verified Homebridge plugins I've used. Just now, I was trying https://github.com/produdegr/homebridge-3em-energy-meter, which is also verified. This is the experience for that:
(You can see that it connected, received a response, but is just endlessly failing at parsing the response.)
I've had similarly bad experiences with:
I'm definitely willing to make the changes mentioned in #527 (comment).
But refactoring from static to dynamic platform is wrong AFAICT. I tried to follow the prescribed best practices when I refactored the unmaintained & unreliable https://github.com/codyc1515/homebridge-sma-inverter project (but thankfully somebody built that! Otherwise getting started would've been much harder!) into something that works reliably.
The examples still list it, so surely it still is a recommended approach?
I'd really like that "Verified" badge to encourage more people to save energy in their home. I can't believe I've been trying this for >6 months at this point. 😞
As a fellow open source maintainer, I applaud your relentless attention to the end user experience! 😊 👏 But AFAICT this plugin is already more reliable than most plugins I've tried. With more precise guidance. With clearer docs. With actual responses from the maintainer. So … why is it not good enough?
bwp91 commentedon Oct 11, 2023
Point taken I won't ask again!
Understood. We are trying to urge developers to always use dynamic-platform-type plugins. About a month ago I updated the homebridge wiki to just have links to the dynamic-platform type template as well as the camera-plugin template.
https://github.com/homebridge/homebridge/wiki
It's a gradual process. And whilst I took the links away from the
homebridge-examplesplugin templates, I didn't want to delete all the repos under this name right now.Sorry it has been a lot of to-ing and fro-ing, but I really am taking into account now what you have said in your last reply, and this verification process in this case I totally understand has been very frustrating for you. This really was never my intention 😅
let me re-run the checks and have another ponder...
bwp91 commentedon Oct 12, 2023
/check
github-actions commentedon Oct 12, 2023
✅ Pre-checks completed successfully.
github-actions commentedon Oct 12, 2023
The plugin must be of type dynamic platform.(N/A)Everything Looks Good!
github-actions commentedon Oct 12, 2023
Congratulations! Your plugin has been verified.
You can now add the Verified by Homebridge badge to your plugin's README:
Your plugin is now also eligible to display a ❤️ Donate button on its tile in the Homebridge UI. See https://github.com/homebridge/homebridge/wiki/Donation-Links for instructions.
If for any reason in the future you can no longer maintain your plugin, please consider transferring it to our unmaintained plugins repo. We can take ownership until another willing developer comes along.
Don't forget to join the official Homebridge Discord server, where plugin developers can get tips and advice from other developers and the Homebridge project team in the #plugin-development channel!
Thank you for your contribution to the Homebridge Community.
https://homebridge.io
rofl0815 commentedon Oct 21, 2023
Hi, i have the latest homebridge 1.6.1 with node.js version 18.16.0 running on a raspberry pi 4 with Buster.
I tried to install homebridge-sma-home-manager v1.1.8 (2023-09-03) and get the following error messages
Do i do something wrong? Thank you.