homebridge-sma-home-manager

wimleers commented 1 year ago

Link To GitHub Repo

https://github.com/wimleers/homebridge-sma-home-manager

Link To NPM Package

https://www.npmjs.com/package/homebridge-sma-home-manager

bwp91 commented 1 year ago

So I have installed the latest version of your plugin, unfortuntately all I seem to get this this:

and checking the status of my child-bridges:

At no point does the circular icon turn to green.

wimleers commented 1 year ago

(Back from vacation.)

It doesn't crash. It doesn't find the necessary devices. Why would it make sense to have the circular icon to turn green, if none of the required devices are present?

The log entries are crystal clear, I think?

If I allow this to launch when no devices are discovered, that would indeed result in a nice "green circular icon". But it'd have one disastrous consequence in case of an ephemeral networking problem that'd prevent the devices from being discovered (e.g. multicasting broke due to router/switch settings changes): HomeKit would think the accessories have been removed, and would automatically also remove them from all automations.

(I know this because I had it happen early on during development. 😨)

I'd much rather have my Homebridge plugins tell me explicitly that the necessary devices are missing and refuse to boot than to potentially quietly mess up my carefully curated automations!

wimleers commented 1 year ago

/check

github-actions[bot] commented 1 year ago

:white_check_mark: Pre-checks completed successfully.

bwp91 commented 1 year ago

Hi @wimleers I appreciate your response.

For platform type plugins, the aim of the green light in the homebridge ui is that that plugin has successfully loaded and started. Not necessarily that it has found every accessory that it is expecting.

We are trying to avoid the log message of

plugin taking a long time to load and preventing homebridge from starting

Are you on the Homebridge discord group? Happy to have a 1:1 message about this

wimleers commented 1 year ago

that that plugin has successfully loaded and started

But if the required hardware is absent or temporarily inaccessible over the network, how does it make sense to make the plugin conclude "success!" and omit the yet-to-be-connected-to accessory, which then results in all automations getting broken? 🙃

🤔 The only alternative I see to fulfill both needs (1. avoid messing up users' automations, 2. always starting the plugin) is to only try for ~30 seconds and if it's not found by then, to just expose the accessories anyway but make them do nothing.

I'll make that happen. 👍

bwp91 commented 1 year ago

Before you start making these changes let me have a discussion with some other maintainers.

I do see your side of this too 😃

bwp91 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

No, I'm facing that because I followed the developer docs at https://github.com/homebridge/homebridge-examples#platform-plugins, which says:

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?

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 https://github.com/homebridge/verified/issues/527#issuecomment-1730936261.

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 commented 1 year ago

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.

Point taken I won't ask again!

No, I'm facing that because I followed the developer docs at https://github.com/homebridge/homebridge-examples#platform-plugins, which says:

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...

bwp91 commented 1 year ago

/check

github-actions[bot] commented 1 year ago

:white_check_mark: Pre-checks completed successfully.

github-actions[bot] commented 1 year ago

[x] - The plugin must successfully install.
[x] - The plugin must implement the Homebridge Plugin Settings GUI.
[x] - The plugin must not start unless it is configured.
[ ] - ~~The plugin must be of type dynamic platform.~~ (N/A)
[x] - The plugin must not offer the same nor less functionality than that of any existing verified plugin.
[x] - The plugin must not execute post-install scripts that modify the user's system in any way.
[x] - The plugin must not contain any analytics or calls that enable you to track the user.
[x] - The plugin must not throw unhandled exceptions, the plugin must catch and log its own errors.
[x] - The plugin must be published to npm and the source code available on GitHub.
[x] - A GitHub release should be created for every new version of your plugin, with patch notes.
[x] - The plugin must run on all Active LTS versions of Node.js, at the time of writing this is Node v18 and v20.
[x] - The plugin must not require the user to run Homebridge in a TTY or with non-standard startup parameters, even for initial configuration.
[x] - If the plugin needs to write files to disk (cache, keys, etc.), it must store them inside the Homebridge storage directory.

Everything Looks Good!

github-actions[bot] commented 1 year ago

Congratulations! Your plugin has been verified.

You can now add the Verified by Homebridge badge to your plugin's README:

[![verified-by-homebridge](https://badgen.net/badge/homebridge/verified/purple)](https://github.com/homebridge/homebridge/wiki/Verified-Plugins)

Your plugin is now also eligible to display a :heart: 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 commented 1 year ago

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

...
make: Verzeichnis „/usr/local/lib/node_modules/homebridge-sma-home-manager/node_modules/@serialport/bindings/build“ wird betreten
  CXX(target) Release/obj.target/bindings/src/serialport.o
g++: error: unrecognized command line option ‘-std=gnu++17’
make: *** [bindings.target.mk:114: Release/obj.target/bindings/src/serialport.o] Fehler 1
make: Verzeichnis „/usr/local/lib/node_modules/homebridge-sma-home-manager/node_modules/@serialport/bindings/build“ wird verlassen
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:203:23)
gyp ERR! stack     at ChildProcess.emit (node:events:513:28)
gyp ERR! stack     at ChildProcess._handle.onexit (node:internal/child_process:291:12)
gyp ERR! System Linux 4.19.97-v7l+
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /usr/local/lib/node_modules/homebridge-sma-home-manager/node_modules/@serialport/bindings
gyp ERR! node -v v18.16.0
gyp ERR! node-gyp -v v9.3.1
gyp ERR! not ok 
npm ERR! code 1
npm ERR! path /usr/local/lib/node_modules/homebridge-sma-home-manager/node_modules/@serialport/bindings
npm ERR! command failed
npm ERR! command sh -c prebuild-install --tag-prefix @serialport/bindings@ || node-gyp rebuild

npm ERR! A complete log of this run can be found in: /home/homebridge/.npm/_logs/2023-10-21T13_40_04_404Z-debug-0.log

Do i do something wrong? Thank you.

homebridge / plugins

homebridge-sma-home-manager #527

Link To GitHub Repo

Link To NPM Package