I really enjoy your work and I actively try using knxweb to
visualize my home automation. I only have a problem when I
try to setup my roller blinds. I have 2 communication
objects 2/4/0 for open/close and 2/4/2 for stop. On 2/4/1 I
expect the status.
I currently can't find any combination of widgets that would
allow for controling these roller blinds.
Is this just jet not available or is there anything I do wrong?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I had the same problem long time ago:
If I press the up / down button, I need to send the first message and after I release the button, I need to send the stop-message.
I have changed the jscript code for doing this and can send it to you.
(I have also done some other changes to the existing classe to add "read-only" visualization (for example for motion detectors or status indicators…, smaller icons for dimmers and blinds…etc)
What I would really would like to have some sort of "plugin" architecture, where soeone like me could develop such extensions and easily add it to the project….
…The problem with this is just the GUI, where one can select the visual object to be added to the project. IMHO this is currently to large and I would appreciate some other kind of menu, where I can first select the object to be added and then get the dialog for the properties. (similar to ETS, Power Project …)
I would do someting like that - if i could.
Jean-Francois, do you think this something to think about???
… I could add some icons and device object like motion detectors and such….:-)
Best Regards, jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
for my blinds/dimer I have simply duplicated the existing "widgets" and modified the code a little. (I have almost no clue of javascript and front-end development - I will provide the code, but I think somebody needs to review and change the things I have done…)
Anyhow, after duplicating the code and giving it a new name, I have to extend the "designedit.html" and "design.html" to make the new widget available.
Using this approach, the "toolbox" (menu) grows further and - when I add a new widget to the list. It gets even worse if the submenu has a lot of additional options (multiple messages, listeners , pictures). My screen is limited and therefore the possibility to have other widgets in the toolbox is also limited. (I call this popup-menu "toolbox" - i don't know, whether this is the right name).
What I would like to have is:
replace all the "new Switch", "New Value Input"," New…" with just one item "New Control".
-> when this is selected, a (new!) popup menu is shown, which lists all the available "plugins" (or controls or widgets-…..) in a categorized way.
The list should be being build dynamically from the available plugins in a subdirectory.
I suggest to have at least a 2-level hierachy, to not list them all in a row, but to have subcontainers like "lights", "shutters"….
What I furthermore have in mind are different "skins" like small or big controls….
When I read the code, I learned, that it is not just the picture, but also code, which is used to show the status for the blinds or the yellow bar for the lights, which is size dependend.
Therefore, if the community helps to develop the plugins, a future "new object" sub-menue hierarchy could look like:
-blinds
|-Type 1
|-Type 1 - small
|-Type 1 - 3d IPAD
|-Type 2
|-Type 2 - small
|-Type 2 - 3d IPAD
- dimmers
|-etc….
etc…
then I select an object with a certain type and style and a (new!) dialog opens, where one can enter additional properties…. (the messages, maybe graphics, maybe some dynamic properties like color…)
But this has to be developed in the "edit_object.js" and highly control-dependant
Some ideas regarding the plugin architecture:
(provided with little frontend-development knowledge :-)
1) to avoid conflicts every plugin should have its own subdirectory.
the subdirectory contains
- pictures
- jscript for execution
- jscript for editing
- css
…
2) every plugin has a "manifest", i.e. a file (xml?), which describes the plugin and is used to build the menu.
Possible Attributes in the manifest:
- Displayname (can contain spaces…this is shown in the "new object" submenu)
- shortname (name of the subfolder and primary ID of the plugin)
- Version?
- Type (Blinds, lights, heating, energy, displays,…….?) - used to build submenues
- Supported Skins (just an option for later, to be able to implement a filter to just show the plugins for a certain skin / multiple skins)
… to be continued another day
Best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is almost what I was looking for.
I found a bug in your code, that you obviously can't find as you change your config in xml.
In the edit script you had all stopObject and stop persistence written with pp (stopp and stoppObject) so the runtime script was unable to read this. I also added some code that when you release the button later than a second after you pressed it, no stop command is issued (similar to the long term object in ETS programmings)
If you want this fix/update back just let me know, I send it to you.
cheers
denghauser
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi denghauser, yes please send it to me - you can just diff the files and let me know. As I said - it was once just a quickfix for myself.
Sorry for being such an egoist :-) …I promise to create a tracker entry - Cyrille might add it to the available controls. I guess there are more users of such blinds.
Thanks, best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also changed you small images (I plan to have a touchscreen) for up and down.
The other change is that I use 3.008 for the stop object. The reason is mentined in the code.
Maybe you want to change this back before submitting this to Cyrille.
I currently like it how it is.
I really love the thing you did, thanks again.
cheers
denghauser
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have updated the widget and did some more coding…
I tried to follow some naming practices and named it "blinds2".
I have now implemented the same behaviour as used in the Busch-Jäger sensors (like solo, triton…) in the widget. You can find more details when following the link:http://autom8.no-ip.org/linknxfan/
For Busch-Jäger the Datatype 3.008 is not working - they use an EIS1 gad with just a 0 / 1 to stop the blinds or let them do a small step. (the 0 is working, of course :-)
@Denghauser: which actors do you use?
Thanks, Best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do use the ABB JA/S actors. I also found that 3.008 is wrong (sorry for the wrong code) it is stated as 1.008 / EIS7 in the documentation of the actor. I kind of was confused with another documentation. Funny enough, it works with the wong code in my environment.
It would be nice if linknx would support different 1 bit types then the listboxes would only contain the available choices.
Have you been able to send/upload the stuff to the jef2000 or cyrille. Would be cool to have this in the standard.
Can I load your current version to see if it works in my environment? Is it on your website?
Thanks
denghauser
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have first prepared the download page and then posted the link….and created a tracker entry for Cyrille. (@Cyrille, maybe there are others, who could use this - would be nice of you if you could add this… :-) )
BUT: I used again the small buttons (because of the reasons I described in the UI discussion) and which you had changed to the big buttons.
There is currently not a single "out of a box" solutions, which fulfills your and my requirements at the same time… that's why I have started the UI discussion to find a common understanding (and avoid double work).
BR, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really enjoy your work and I actively try using knxweb to
visualize my home automation. I only have a problem when I
try to setup my roller blinds. I have 2 communication
objects 2/4/0 for open/close and 2/4/2 for stop. On 2/4/1 I
expect the status.
I currently can't find any combination of widgets that would
allow for controling these roller blinds.
Is this just jet not available or is there anything I do wrong?
Thanks
Hi,
I had the same problem long time ago:
If I press the up / down button, I need to send the first message and after I release the button, I need to send the stop-message.
I have changed the jscript code for doing this and can send it to you.
(I have also done some other changes to the existing classe to add "read-only" visualization (for example for motion detectors or status indicators…, smaller icons for dimmers and blinds…etc)
What I would really would like to have some sort of "plugin" architecture, where soeone like me could develop such extensions and easily add it to the project….
…The problem with this is just the GUI, where one can select the visual object to be added to the project. IMHO this is currently to large and I would appreciate some other kind of menu, where I can first select the object to be added and then get the dialog for the properties. (similar to ETS, Power Project …)
I would do someting like that - if i could.
Jean-Francois, do you think this something to think about???
… I could add some icons and device object like motion detectors and such….:-)
Best Regards, jens
Hi,
I am also thinking to implement a better "plugins" architecture.
I don't really understand what you mean about the kind menu you want, could you please explain more clearely?
About the changes you have made, you can post a patch to the tracker so we can implement it in the CVS.
Regards,
Cyrille
Hi Cyrille,
for my blinds/dimer I have simply duplicated the existing "widgets" and modified the code a little. (I have almost no clue of javascript and front-end development - I will provide the code, but I think somebody needs to review and change the things I have done…)
Anyhow, after duplicating the code and giving it a new name, I have to extend the "designedit.html" and "design.html" to make the new widget available.
Using this approach, the "toolbox" (menu) grows further and - when I add a new widget to the list. It gets even worse if the submenu has a lot of additional options (multiple messages, listeners , pictures). My screen is limited and therefore the possibility to have other widgets in the toolbox is also limited. (I call this popup-menu "toolbox" - i don't know, whether this is the right name).
What I would like to have is:
replace all the "new Switch", "New Value Input"," New…" with just one item "New Control".
-> when this is selected, a (new!) popup menu is shown, which lists all the available "plugins" (or controls or widgets-…..) in a categorized way.
The list should be being build dynamically from the available plugins in a subdirectory.
I suggest to have at least a 2-level hierachy, to not list them all in a row, but to have subcontainers like "lights", "shutters"….
What I furthermore have in mind are different "skins" like small or big controls….
When I read the code, I learned, that it is not just the picture, but also code, which is used to show the status for the blinds or the yellow bar for the lights, which is size dependend.
Therefore, if the community helps to develop the plugins, a future "new object" sub-menue hierarchy could look like:
-blinds
|-Type 1
|-Type 1 - small
|-Type 1 - 3d IPAD
|-Type 2
|-Type 2 - small
|-Type 2 - 3d IPAD
- dimmers
|-etc….
etc…
then I select an object with a certain type and style and a (new!) dialog opens, where one can enter additional properties…. (the messages, maybe graphics, maybe some dynamic properties like color…)
But this has to be developed in the "edit_object.js" and highly control-dependant
Some ideas regarding the plugin architecture:
(provided with little frontend-development knowledge :-)
1) to avoid conflicts every plugin should have its own subdirectory.
the subdirectory contains
- pictures
- jscript for execution
- jscript for editing
- css
…
2) every plugin has a "manifest", i.e. a file (xml?), which describes the plugin and is used to build the menu.
Possible Attributes in the manifest:
- Displayname (can contain spaces…this is shown in the "new object" submenu)
- shortname (name of the subfolder and primary ID of the plugin)
- Version?
- Type (Blinds, lights, heating, energy, displays,…….?) - used to build submenues
- Supported Skins (just an option for later, to be able to implement a filter to just show the plugins for a certain skin / multiple skins)
… to be continued another day
Best Regards, Jens
Hi Dietmar,
you can find the code which supports your blinds here:
http://autom8.no-ip.org/linknxfan/
Best Regards, Jens
Hi Jens,
this is almost what I was looking for.
I found a bug in your code, that you obviously can't find as you change your config in xml.
In the edit script you had all stopObject and stop persistence written with pp (stopp and stoppObject) so the runtime script was unable to read this. I also added some code that when you release the button later than a second after you pressed it, no stop command is issued (similar to the long term object in ETS programmings)
If you want this fix/update back just let me know, I send it to you.
cheers
denghauser
Hi denghauser, yes please send it to me - you can just diff the files and let me know. As I said - it was once just a quickfix for myself.
Sorry for being such an egoist :-) …I promise to create a tracker entry - Cyrille might add it to the available controls. I guess there are more users of such blinds.
Thanks, best Regards, Jens
Hi Jens,
you can load my changes from here
I also changed you small images (I plan to have a touchscreen) for up and down.
The other change is that I use 3.008 for the stop object. The reason is mentined in the code.
Maybe you want to change this back before submitting this to Cyrille.
I currently like it how it is.
I really love the thing you did, thanks again.
cheers
denghauser
Hi,
I have updated the widget and did some more coding…
I tried to follow some naming practices and named it "blinds2".
I have now implemented the same behaviour as used in the Busch-Jäger sensors (like solo, triton…) in the widget. You can find more details when following the link:http://autom8.no-ip.org/linknxfan/
For Busch-Jäger the Datatype 3.008 is not working - they use an EIS1 gad with just a 0 / 1 to stop the blinds or let them do a small step. (the 0 is working, of course :-)
@Denghauser: which actors do you use?
Thanks, Best Regards, Jens
Hi Jens,
I do use the ABB JA/S actors. I also found that 3.008 is wrong (sorry for the wrong code) it is stated as 1.008 / EIS7 in the documentation of the actor. I kind of was confused with another documentation. Funny enough, it works with the wong code in my environment.
It would be nice if linknx would support different 1 bit types then the listboxes would only contain the available choices.
Have you been able to send/upload the stuff to the jef2000 or cyrille. Would be cool to have this in the standard.
Can I load your current version to see if it works in my environment? Is it on your website?
Thanks
denghauser
Hi denghauser,
I have first prepared the download page and then posted the link….and created a tracker entry for Cyrille. (@Cyrille, maybe there are others, who could use this - would be nice of you if you could add this… :-) )
BUT: I used again the small buttons (because of the reasons I described in the UI discussion) and which you had changed to the big buttons.
There is currently not a single "out of a box" solutions, which fulfills your and my requirements at the same time… that's why I have started the UI discussion to find a common understanding (and avoid double work).
BR, Jens