-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support CCU-Jack #164
Comments
Hi @just-grizzle, |
Ok, I get that. |
hi everyone. CCU-Jacks "primary" feature is about exposing existing ccu devices in new ways esp. mqtt. i think there is not a lot that needs to be integrated to benefit from that on node-reds side because mqtt is already there of course. but its "secondary" feature is to allow for arbitrary new (virtual) devices to be materialized in the ccu, also with the intention to further support mqtt protocol, very similar to CUxD that also aims to have new classes of devices provided based on their primary state management protocol. while CUxD also allows for naked abstract devices assuming you use cmd and scripting to implement its state logic yourself, it lacks a plain way to do so for mqtt devices such as tasmota devices for example. so for people like me, that are using a lot of tasmota devices (or any other mqtt devices) and those used to be implemented with hardcoded wget/curl commands in ccu scripts or CUxD cmd devices (and they additionally depend on the devices ips are static), this secondary feature becomes a major game changer because now any mqtt device can be integrated smoothly without scripting, commands and static device ips. then i found out that just like CUxD devices CCU-Jack devices need to be connected to node-red in a special way regarding api and protocol and that special treatment is not a lot about implementation but merely "only configuration" of the CCUs apis and protocols in red-matic. so the use cases here are: as a ccu owner with installed devices based on CCU-Jacks virtual mqtt devices feature in node-red i can now wire (and browse) them just like any other ccu devices in node-red / red-matic. probably that would be obsolete if node-red has a better way to integrate mqtt devices (independently), i am probably not aware of. but even then, the price of allowing that additional api/protocol for that new "class" of ccu devices is pretty low. |
Hi, the primary use case is that
Just my 2 cents.... guenni |
thats not a use case, its a list of arguments... for... removing contrib-ccu? this very issue is about enabling contrib-ccu to also work with ccujacks virtual devices directly next to the other types of devices it can already directly talk to via contrib-ccu. if contrib-ccu had been invented after ccujack, the missing link would have been there from the start. i consider ccujack as a "game changer" for homematic, thats why i promote this feature. i also consider node-red (via "redmatic" and contrib-ccu) as a "game changer" for homematic, so in my eyes these two factors in the end also multiply. i fully admit that if ccujack had been invented more early in the past and would by the time be a defakto-standard for the ccu like cuxd already is, it is very likely that the connection between ccu and node-red would have been built on top of mqtt generally instead of a salad of apis. nevertheless if this is now becoming a "do we need redmatic/contrib-ccu at all" then i want to reply: yes! redmatic/contrib-ccu mainly brings node-red directly on the ccu and consists of more than the nodes visible in node-red. a lot of use cases that cause headache on a naked ccu to implement become a lot easier just with the snap of a finger and the installation of redmatic on top of the ccu with the very good help of contrib-ccu. i consider redmatic and node-red on the ccu itself as the primary value for homematic people even if i would also say that running it on a separate machine is also a desireable feature i would expect to generally work. a lot of "open issues" relate to a separate installation. i d admit that probably that setup increases the number of potential edge cases that one could stumble over. a lot of other issues are plain feature requests which of course suffer from a lacking devloper base. i can only say that the day i decided to finally give redmatic a try and hit the "install" button on the ccu was followed by hours of "aaaaahs" and "ooooohs" because it perfectly fits on top without the claim to replace it or to be another animal in the zoo that needs extra love and food. homematic benefits a lot from node-red as an "extension" to it. and i hope node-red benefits from redmatic because the user base increases potentially. i hope node-red-contrib-ccu gets back lacking maintainers, but the fact that it probably is too quiet there also can be related to the fact that it generally simply works. polling of anything is not optimal but this is also only a edge case. for example i replaced system variables i needed to talk to in node-red with ccujack virtual devices and voila. system variables i think are not intended to be apis in the first place. if redmatic gets refactored to use ccujack/mqtt instead of xml/rpc apis i personally would also be happy with it but i would not recommend to let people build their own mqtt wires to and from ccu instead of being able to directly refer to ccu devices. |
I 100% FULLY agree with all points. Enabling contrib-ccu to work with cpu-jack was my original proposal mdzio/ccu-jack#75 |
Hi all,
I saw @realgnark's pull request #162 about support for the CCU addon "CCU-Jack" (repo here).
I'd like to discuss your opinions about that.
For my understanding, CCU-Jack is a connector which translates the XML RPC API to HTTP or MQTT. So what are the use cases when supporting this in Node-RED?
Regards Grizzle
The text was updated successfully, but these errors were encountered: