@Kai - do you have another way we’d be able to achieve the goal here? I get the details you explain about open source vs closed like this is. Any possibility it’s something that can be handled through the foundation? Don’t want to make @chris life difficult, but I’d assume it could be better in the long run so that Chris doesn’t have to “own” the dev kit, the foundation could. Ensuring it could stay with the project from all the donations. Assuming at that point, then folks working on the code, would be privy to the details.
Just throwin out an idea, not sure of any legalities to deal with proprietary type info like this. It is a bit of a sticky situation. But the positive here is there are a lot of us happy to help out in making the donations to fund such an effort.
Just to be clear, there would still be an OS version. What I’m proposing is to have another “transport layer” that is not OS (due to the licensing constraints) that allows us to support things that are not currently possible due to lack of information. We know from personal discussions with Sigma that they have no intention of making this part of ZWave public any time soon.
To me, there are the two options - we either continue as we are with the open source binding that probably has issues, and certainly lacks features that people are regularly asking for, or, we provide an alternative and this must be closed source.
I suspect it would be difficult for the foundation to handle this due to the legal bumf that has to be signed to. In any case, while it’s a not an insignificant amount of money, I already spend a lot of money to support this binding and the users on this forum by purchasing equipment for testing etc. I don’t see anyone complaining, and to me this is a very similar situation (although if the foundation also wants to buy all my test hardware then I’m sure we can do a deal ).
I will move ahead with this to try and better support this. Some of the information should be able to go straight into the OS code (where it’s simply a better understanding of published standards) and my intention is to keep the closed source part as small as possible to stay within the legal requirements. As above, the intention is to always retain the OS version of this based on the existing codebase and if someone wants to improve that based on information that may be made publicly available, then that is always an option in exactly the same way it is now.
I have not asked for money to do this - someone asked how much it would cost and I answered. Clearly recouping some of my costs would be very nice, and I certainly appreciate the donations. If I’m somehow breaking OH rules then I apologise, and I will make this available outside of the direct OH channels.
I’m not sure if I’m asking the obvious here, but would it be possible to have the closed source portion as an option? So those who are very much against using closed source stuff could use the binding anyway (but then with “degraded” functionality)?
I’ve been having quite much problems with my z-wave network so I’ll be happy for anything that makes it more stable (although I’m not sure about the problem being the binding or my z-stick having some kind of fault). I don’t think it would be fair though to let @chris pay for this on top of all the time being spent on developing this binding, so I’m fully in for donating some bucks.
I doubt that this would be possible. Note that the purpose of the foundation is to “educate the public about open source smart home” - and all activities must pay into this mission, otherwise we risk losing our not-for-profit status; and the German tax authorities are pretty strict on that… So buying dev kits in order to facilitate close source developments (and then possibly “owning” this closed source code) is probably nothing that is in line with the foundation’s purpose.
Don’t want to make @chris life difficult, but I’d assume it could be better in the long run so that Chris doesn’t have to “own” the dev kit, the foundation could
It is not that much owning the dev kit, but rather owning the close source code. The normal Z-Wave case is that a company buys the dev kit and builds a product using the closed source. This solves issues like code ownership and the distribution and licensing of the binary. I think this is something to clarify first as otherwise supporters might donate to the efforts with wrong expectations - not that anybody wishes that anything happens to Chris, but there might be many reasons why he might suddenly not be available anymore, in which case the whole closed source would be lost as it cannot be accessed or transferred. So having a legal entity being the owner of the code would imho avoid the bus factor issues. Ideally, Sigma would directly host and distribute such a jar, maybe it would be worth to discuss this idea with them!
Don’t get me wrong, I am the last one to not agree that you deserve any penny that people are willing to donate for all your work! And no, it is absolutely fine if this is discussed and arranged here in the forum; I mainly wanted to point out that BountySource might not be the right tool, a direct Paypal transfer might be simpler. And I wanted to help clarifying expectations of all sides, as close source brings up new challenges to the project and its users - see above.
I don’t think they are very interested in this route. They are heavily pushing the ZIP interface which has other issues (as we have discussed elsewhere).
My intention would be to run this through my company due to the legal issues that surround it. While I always try and avoid getting hit by a bus I’m not sure that it’s so easy to transfer this due to the legal paperwork (and the devkit is non transferable).
I really don’t want to make this difficult - if we start talking about setting up separate legal entities to manage this then I think it will go into the “too hard” basket. I’m simply trying to offer a route that provides additional functionality to improve the current binding. I really want to keep it as minimal as possible so that (something like) 97% of the binding remains open and we just have this lite transport layer with the open variant.
But I guess we already have a similar situation for things like the ZWay binding (and there’s possibly others) where people wanting to use this software have to pay a license of 10 or 15 dollars I think. This requires closed source apps to support it so arguably the only difference is that the closed source element is not part of OH, but the model isn’t that dissimilar I think…
No, definitely not my idea either, that would be far too much effort for a little bit of code
In all other cases it is something external (a separate process, another software, a piece of hardware) to openHAB, while here we are talking about a piece that has to be deployed on the openHAB runtime itself. Probably the best would be a jar that could be put in the add-ons folder and which would be picked up and used by the Z-Wave binding, if present - is that your idea?
What would be the license regarding re-distribution of such a jar? Would people be allowed to use it free of charge for any purpose they like? Are they free to redistribute it to others?
Yes - my initial thought was to allow different JARs to be added to implement a transport service - similar to some of the BLE architecture concepts we looked at. I guess there’s various options as to the exact implementation, but something along those lines…
To be honest, I’d not thought about the detail here. Certainly for OH2 users use it should be free and redistributable.
Sorry guys didn’t mean to de-rail this and chase down a rabbit hole, or confuse the plans that Chris had on his own. I just saw an opportunity for us the users to be able to help push this effort forward by helping to cover the costs Chris incurs. My apologies if I confused the messaging and the plans here.
Bottom line from me: happy to help put some more toward official support if it means we might be able to find the issue with the corner problems. I’m assuming one of those @chris is relative to what I and a few others seems to have in common with the inability to include securely when there is a plethora of devices already included to my ZStick. Perhaps it makes sense to open a separate thread about such an effort so we don’t de-rail this one?
I just purchased a Leviton DZ1KD-1BZ Decora Smart 1000W Dimmer to replace an DZ6HD-1BZ that was causing the lights to flicker. Unfortunately the DZ1KD-1BZ is not in the database. If it’s added to the database do I need to upgrade my binding before it will appear in openhab?
This happens occasionally - it occurs at 15 minutes past even hours I think and will last 30 seconds or so. It’s linked to the regular backup and I’ve not yet worked out how to do the backup without this…
I just have to say it, java + closed source is funny. Years ago I had to write a little app that attaches to the JVM and lists currently executing modules so you can dump the .class from them. I used this to extract a class that was in a ridiculously expensive obfuscation package so that I could cavaj the code and enhance it. It’s hard to have closed source in an interpreted language.
What are all these errors I’m getting? Known issue?
2017-08-20 17:00:12.123 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 24: Sent Data was not placed on stack.
2017-08-20 17:00:12.165 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-08-20 17:00:12.179 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-08-20 17:00:12.193 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 27: Sent Data was not placed on stack.
2017-08-20 17:00:12.220 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 54: Sent Data was not placed on stack.
2017-08-20 17:00:12.231 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 29: Sent Data was not placed on stack.
2017-08-20 17:00:12.251 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 26: Sent Data was not placed on stack.
2017-08-20 17:00:12.265 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-08-20 17:00:14.446 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 26: Sent Data was not placed on stack.
2017-08-20 17:00:14.455 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 24: Sent Data was not placed on stack.
2017-08-20 17:00:14.465 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 54: Sent Data was not placed on stack.
2017-08-20 17:00:17.714 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 24: Sent Data was not placed on stack.
2017-08-20 17:00:17.743 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 54: Sent Data was not placed on stack.
2017-08-20 17:00:17.758 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 26: Sent Data was not placed on stack.
openhab> bundle:list | grep Z
15 â Active â 80 â 126.96.36.199708201145 â ZWave Binding