zwave compatibility with OH2

[Chris Jackson]

Unfortunately, the OH1 zwave binding doesn't seem to work with OH2. I'll try and set up the dev environment and work out what's up over the next few weeks (probably one for Christmas :) ).

Chris

[Marcel Verpaalen]

Great news.. Once the zwave binding is working I can use OH2 as my main one.

Are you also planning on making habmin work again or will it completely be replaced by the new gui?

Op woensdag 10 december 2014 23:07:06 UTC+1 schreef Chris Jackson:

[Kai Kreuzer]

Hi Chris,

Sounds great, please count on my support if you come across problems!

Are you also planning on making habmin work again or will it completely be replaced by the new gui?

This is also something I would like to discuss with Chris. I do not see the „new gui“ as a full replacement for his work in HABmin - especially wrt Z-Wave, so I would go for trying to make it compatible as well. Chris, you will actually like that the REST API is now nicely extensible :-)

Nonetheless, we should also check how Z-Wave fits into the new thing architecture - having thing descriptions and auto-discovery through the new mechanisms is quite appealing!

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/472d2a37-fce6-48fa-be38-afc566a8958c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Jackson]

Thanks Kai,

Is there a pointer on setting up the dev environment. I think I read somewhere you were going to write something up in December, so I guess this isn't done yet (no hurry - just asking in case I missed it).

Re HABmin..... I'm not supporting the current version (people may or may not have noticed this :) ). I've been working on a new version based on the Angular framework. I currently supports graphing, zwave, sitemaps (although poorly!) and the graphical rule designer. It's currently embedded within the HABmin repository but I'll likely break it out separately in the near future (christmas break maybe)...  Once I get the OH2 dev environment up, I'll probably look at how to support discovery etc. Kai - I'm happy to discuss as always...

Cheers

Chris

[Kai Kreuzer]

Hi Chris,

Is there a pointer on setting up the dev environment. I think I read somewhere you were going to write something up in December, so I guess this isn't done yet (no hurry - just asking in case I missed it).

For the IDE, you can have a look here: https://github.com/openhab/openhab2/blob/master/docs/sources/installation/compatibilitylayer.md#how-to-solve-problems-with-a-certain-add-on

You are right, I also planned to do a short screencast to show this, but I didn’t yet find the time for it :-(

Re HABmin..... I'm not supporting the current version (people may or may not have noticed this :) )

Good to know, I actually hadn’t noticed :-)

. I've been working on a new version based on the Angular framework. I currently supports graphing, zwave, sitemaps (although poorly!) and the graphical rule designer.

Hm, then you should definitely liaise with Dennis and join forces - you might have seen that the new Paper UI is also based on AngularJS (as this was actually your suggestion) and it (will soon) drop the Polymer part in it… Graphing is something I want to see in there as well (using your REST API extensions for time-series) and sitemap support is also completely missing so far (and ZWave-Setup obviously as well). You both could actually pretty much complement each other - Dennis' focus is currently on all the administration of inbox, things and items. We should probably start a separate thread about this (or continue at https://bugs.eclipse.org/bugs/show_bug.cgi?id=440012, which you might have noticed is assigned to Dennis at the moment).

Best regards,

Kai

[Chris Jackson]

Thanks Kai,

I'll take a look at the IDE install...

I had noticed that the PaperUI had Angular behind :) I've not looked at it much, other than a very quick play with the GUI and a quick scan at the source in Github to see what the framework was...

For HABmin, I've attached a few screenshots - I've gone with a different look, but it ought to be customisable as I'm using a bootstrap theme system. Some parts have had more effort than others - sitemaps only support some widgets (mostly the main ones I'm using :) ), and the styling is a bit poor still....

I want to split this out to a separate repository at some stage soon and I'm more than happy to link the two if it fits...

Cheers

Chris

[Ben Jones]

Just wow Chris - that new UI looks fantastic. God knows how you find the time to do all this incredible work!!

[Kai Kreuzer]

Hi Chris,

Ben is right - this is really incredible! You shouldn’t do such stuff so hidden and in complete silence - this is worth to talk about!

I like the look, it is very professional. Reminds me a bit of the GIRA clients. It is great for PCs or large screens, but obviously not meant for touch usage on phones or tablets. That’s again something where it nicely complements Dennis’ work, which uses material & responsive design for touch devices.

From a user/device perspective it does not make sense to mix both approaches - you would want all tabs appear in the same manner. But from a technical perspective, I would prefer to have a single UI framework, which more or less allows tabs of both sorts, but dependent on the user+device only shows the one or the other (or best a configurable set of tabs).

I am not in the technologies enough to assess whether this makes sense and if there can be synergies or if we rather need to go for separate UIs for touch & PC.

@Chris, @Dennis, what is your opinion on this?

Regards,

Kai

Am 11 Dec 2014 um 20:14 schrieb Ben Jones <ben.j...@gmail.com>:

Just wow Chris - that new UI looks fantastic. God knows how you find the time to do all this incredible work!!

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/a01ab03f-b541-4326-ad9d-627d00b2c2f0%40googlegroups.com.

[Chris Jackson]

Hi Kai,

The nice thing about using Bootstrap as the UI framework (on top of Angular as the application framework) is it works fine with touch as well - and it's responsive. However, the layout with the charting (with the list on the left and graph on the right) isn't ideal for smaller screens as it folds so the list is above and the chart below (at least on the phone - it's fine on the tablet). It works pretty well on my Android phone, and my tablet (and of course the PC). It does need a bit more styling for these devices to make the layout a bit nicer (maybe hiding some buttons when the screen gets smaller), but it works reasonably well given I've not made a lot of effort to on this yet...

I'm guessing the Paper UI is likely to be the same - it's the way of the world these days - people don't really want to design multiple UIs, it should just work on whatever device. On the other hand,from the user perspective, people have different likes and dislikes when it comes to UIs, so I'm not sure if there's a one size fits all anyway (??)

I'll see if I can get a working version of this available over the weekend to play with...

Chris

[Dennis Nobel]

Hi Chris,
Hi Kai,

regarding responsibility I fully agree. A modern UI should support all device screens, beginning from mobile up to a large desktop. I don´t see a need for different UIs for different resolutions. Typically it depends a little bit what is your focus, but it is possible to tweak the look of a user interface individually for each resolution with little effort. Btw: the Paper UI also uses Twitter Bootstrap for the grid layout and responsiveness, but Googles Paper Elements for the widgets and inputs.

From the screenshots it looks like your user interface is in an advanced state, maybe even more complete than the Paper UI at the moment. I´m not sure if it will be possible to include one UI into the other. Angular JS gives you a lot of space for development. Thus I assume the implementation looks completely different. The look is also completely different. So at least one of the UIs must be hardly refactored to fit into the another. 

Some functionalities are implemented twice, e.g controlling and device configuration. I´m just wondering what kind of API you use for configuration. Do you use the new Thing REST API? I also plan to include rule management, when the new rule engine is finished. But I´m not sure about sitemap support now.

So I actually have no real idea how to proceed. For me it is also not a problem to have multiple UIs, so the user can choose the one he likes. Maybe the UIs have different focusses - e.g. advanced technical users vs. basic users . I´m also open for discussions how to combine the approaches or how to bring it together, but as I said I think both UIs are completely different, so it will be quite difficult. The plan for the Paper UI  on the long term was also a contribution to Eclipse SmartHome, so that other (possibly commercial) projects can use and benefit from it.

Dennis

[Kai Kreuzer]

regarding responsibility I fully agree. A modern UI should support all device screens, beginning from mobile up to a large desktop. I don´t see a need for different UIs for different resolutions.

I do not fully agree here. This is a bit what Microsoft tried with Metro and failed badly: To have a UI design that is likewise suitable for touch and for mouse. So yet - both cases can be suitable for screens of all sizes, but a touch-optimised UI might not be the best choice to use at a PC with a mouse and vice versa.

If I look at Chris’ chart buttons, they are nice for using them with a mouse, but I would rather not use them by touch, but expect pinch & zoom possibilities here.

Thus I assume the implementation looks completely different. The look is also completely different. So at least one of the UIs must be hardly refactored to fit into the another. 

My (maybe dilettante) idea would be to only merge the main menu (the tabs) together and have the different tabs done in different ways. I would expect that the different tabs could be somehow treated like separate applications. If then both of you would implement the same themes (i.e. a paper theme like Dennis and a dark theme like Chris), this could already move closer together.

I´m just wondering what kind of API you use for configuration. Do you use the new Thing REST API?

Some history for you: With HABmin, Chris added functionality to openHAB that allows manipulating the DSL files through the REST API. As I always had in mind to build an Xtext-less runtime, I never made HABmin a part of the official distribution as this would have „officially confirmed“ this functionality. As I couldn’t offer any other way for Chris though, I was fine with doing this in HABmin. Now with the new thing concept, I would like to find a way with Chris to migrate his work - that’s how the discussion here started today.

So I actually have no real idea how to proceed. For me it is also not a problem to have multiple UIs, so the user can choose the one he likes. Maybe the UIs have different focusses - e.g. advanced technical users vs. basic users . I´m also open for discussions how to combine the approaches or how to bring it together, but as I said I think both UIs are completely different, so it will be quite difficult.

If my suggestion from above could work out, I can imagine that there can be many synergies in the end: User preference settings, localization, chart libraries, notification support etc. So I somehow feel that having two competing UIs doing many similar things, but slightly different, is not the best way to move forward.

The plan for the Paper UI  on the long term was also a contribution to Eclipse SmartHome, so that other (possibly commercial) projects can use and benefit from it.

We also discussed that in general it should be possible to extend the UI by new tabs through others. So if you both manage to merge your approaches, this would be a first proof that this can be feasible. :-) Am I too naive...?

Best regards,

Kai

Am Donnerstag, 11. Dezember 2014 21:38:32 UTC+1 schrieb Chris Jackson:

Hi Kai,

The nice thing about using Bootstrap as the UI framework (on top of Angular as the application framework) is it works fine with touch as well - and it's responsive. However, the layout with the charting (with the list on the left and graph on the right) isn't ideal for smaller screens as it folds so the list is above and the chart below (at least on the phone - it's fine on the tablet). It works pretty well on my Android phone, and my tablet (and of course the PC). It does need a bit more styling for these devices to make the layout a bit nicer (maybe hiding some buttons when the screen gets smaller), but it works reasonably well given I've not made a lot of effort to on this yet...

I'm guessing the Paper UI is likely to be the same - it's the way of the world these days - people don't really want to design multiple UIs, it should just work on whatever device. On the other hand,from the user perspective, people have different likes and dislikes when it comes to UIs, so I'm not sure if there's a one size fits all anyway (??)

I'll see if I can get a working version of this available over the weekend to play with...

Chris

-- 
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/e2871cd6-4394-4d48-9831-a8289682ed02%40googlegroups.com.

[Dennis Nobel]

Am Donnerstag, 11. Dezember 2014 23:06:38 UTC+1 schrieb Kai Kreuzer:

regarding responsibility I fully agree. A modern UI should support all device screens, beginning from mobile up to a large desktop. I don´t see a need for different UIs for different resolutions.

I do not fully agree here. This is a bit what Microsoft tried with Metro and failed badly: To have a UI design that is likewise suitable for touch and for mouse. So yet - both cases can be suitable for screens of all sizes, but a touch-optimised UI might not be the best choice to use at a PC with a mouse and vice versa.

If I look at Chris’ chart buttons, they are nice for using them with a mouse, but I would rather not use them by touch, but expect pinch & zoom possibilities here.

OK, Microsoft did a bad Job at this point, right ;). But meanwhile there a good solutions for touch gestures also in graphs. It just must be supported. But you don´t need a complete different UI, you only have to take care of touch and mouse support, ideally with the same priority. 

Thus I assume the implementation looks completely different. The look is also completely different. So at least one of the UIs must be hardly refactored to fit into the another. 

My (maybe dilettante) idea would be to only merge the main menu (the tabs) together and have the different tabs done in different ways. I would expect that the different tabs could be somehow treated like separate applications. If then both of you would implement the same themes (i.e. a paper theme like Dennis and a dark theme like Chris), this could already move closer together.

Theme its not only the color, I think the whole design is different. See also the next comment above.

I´m just wondering what kind of API you use for configuration. Do you use the new Thing REST API?

Some history for you: With HABmin, Chris added functionality to openHAB that allows manipulating the DSL files through the REST API. As I always had in mind to build an Xtext-less runtime, I never made HABmin a part of the official distribution as this would have „officially confirmed“ this functionality. As I couldn’t offer any other way for Chris though, I was fine with doing this in HABmin. Now with the new thing concept, I would like to find a way with Chris to migrate his work - that’s how the discussion here started today.

So I actually have no real idea how to proceed. For me it is also not a problem to have multiple UIs, so the user can choose the one he likes. Maybe the UIs have different focusses - e.g. advanced technical users vs. basic users . I´m also open for discussions how to combine the approaches or how to bring it together, but as I said I think both UIs are completely different, so it will be quite difficult.

If my suggestion from above could work out, I can imagine that there can be many synergies in the end: User preference settings, localization, chart libraries, notification support etc. So I somehow feel that having two competing UIs doing many similar things, but slightly different, is not the best way to move forward.

I share your feeling. But I´m not sure if this can be prohibited. I guess Paper UI and Chris UI will not be the last tries to come up with a UI for openHAB. But I agree that it would be better for the user to bundle our energy into one good application, than having two applications, which have a lot of common functionalities.

The plan for the Paper UI  on the long term was also a contribution to Eclipse SmartHome, so that other (possibly commercial) projects can use and benefit from it.

We also discussed that in general it should be possible to extend the UI by new tabs through others. So if you both manage to merge your approaches, this would be a first proof that this can be feasible. :-) Am I too naive...?

Well, the idea is still to have extensions. But I thought of extensions, that use the same widgets and components and make use of the theme and services for communication, so that the UI feels unique and the development effort is not that high. And these extensions should more a less bring in a small piece of functionality, or a submodule as "rule management" for example. Chris UI looks more like a complete application, that could also provide extensions. Even if Chris would make his UI white, they look completely different and they have different conceptional design and usability. So in that case I think it will not be a good experience for the user if we would integrate all kinds of applications into one UI. For that we could better use the dashboard as entry point into different apps.

[Stefan K.]

Hi,

just my two cents about the interface discussion:

As an "Enduser" i expect the same experience what my device/os brings with e.g. for an iOS device i would like to see a native app on the phone with "Apple experience" and not an HTML App in an browser with a different style and usage.

So i would recommend:

• native app for Android/iOS/(WP) with support for tablets (mainly touch driven)
• HTML App with an responsive design that they also fit for smaller and bigger screens (mainly mouse driven)

Make sense?

Cheers

Stefan

[Kai Kreuzer]

Make sense?

Only if you tell us who is going to maintain all these different versions ;-)

Especially for setup & configuration aspects, I do not see that this will be covered by all UIs. One HTML5-based app should be enough (at least for a start) and instead of having two technological similar UIs competing, I think it would make a lot more sense to join forces to have one really great one.

For the „daily use“, I agree that native apps (as they currently exist for openHAB) are important to have.

Regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/e4486399-48fa-4e1d-b358-f7e31656bed8%40googlegroups.com.

[Davor Fikais]

Hello!

Would it be possible to have a native apps for Android/iOS/WP that would basically have a full screen HTML-5-based web browser inside (because there is no need for address bar and such a things), and only one webpage that they would open (in settings - address of OpenHAB server)? That would minimize the need of native programming, but still would allow users to have more space for items on small screens and dedicated app for OpenHAB. 

Best regards, 

Davor

[Chris Jackson]

> Would it be possible to have a native apps for Android/iOS/WP that would basically have a full screen HTML-5-based web browser inside (because there is no need for address bar and such a things), and only one webpage that they would open (in settings - address of OpenHAB server)? That would minimize the need of native programming, but still would allow users to have more space for items on small screens and dedicated app for OpenHAB.

Yes, in fact, this was my plan with HABmin, and it could be done with PaperUI (or other UIs) as well. In the past I’ve used PhoneGap which can compile JS into a native app - it’s not quite as good as writing a native app from the get-go, as it can be slower and the interface just isn’t quite the same as a native app, but it’s a million times easier than supporting multiple versions.

I’ve not tried compiling the latest HABmin yet - I’ve used it previously on other projects though and have been meaning to try it with the latest source to see how well it works.

Chris

[Davor Fikais]

Regarding the speed issue, I don't see problem there, because (my opinion only) OpenHAB is not something you would spend working with few hours daily. So, small lag should not be a big issue. I'm just not sure how well is HTML-5 support in mobile browsers, because current version of HABmin (1.X) does not render well in Chrome for Android. If it could be rendered the same way as desktop Chrome does, and without additional stuff that take space on the screen, it would make a good UI (especially after seeing screenshots You've posted earlier).

Best regards,

Davor

[Chris Jackson]

Yes - I hope speed isn’t an issue, but previously I was using ExtJS (as also used in the current version of HABmin), and it could be REALLY slow. I’ve not compiled it up on the latest version but will give it a try at some stage soon (it’s something I’ve been meaning to do for a while).

ExtJS (i.e. the current HABmin) doesn’t support a responsive interface, so won’t scale well to other phones/tablets etc. The new version does, although depending on what you’re doing, a small phone may not be ideal. For example, you can edit the graphical rules on your phone - it works, but there’s really too little real-estate available to do it justice…

Chris

[ge...@ge-volution.eu]

Hi guys,

Just adding a couple thoughts...

Although I agree with the concept of having a single UI for multiple devices which is responsive, I also agree that the needs and use on a PC can be quite different then on a tablet.  I am mostly referring to the charts here... Although it may be possible to incorporate both elements like pinch to zoom on a tablet and mouse wheel use for zooming on a PC, I think that it is important not to lose sight of what one may want to do on say a PC versus a tablet.  I am thinking of more advanced chart controls like selecting a region on a chart for either data selection or zooming, as well as hovering over data points to see there value, as well as sideways scrolling through time. 

Should you guys be able to build an interface that can do all these things regardless of the device, I think you're awesome (for one), and for two, I think that it would avoid people going off and building their own things should the base OpenHAB platform not be able to fully accommodate their needs.

And Chris... really nice work on the new HABmin interface.  I admit that this is the sort of thing that I am hoping to build at home (and work?).

I also agree with Kai that even getting the base UI structure working similarly is a start for a future common UI platform as well as more seamlessly coupling HABmin with OH2 and Paper UI.

Greg

[Chris Jackson]

The charting works with pinch to zoom (etc) on tablets, and scroll wheel etc on a PC. There’s always multiple actions you want to do on a chart, so there’s always compromise here (wether it’s on a tablet/phone, or PC), but I think it works reasonably well…

I’ll try and get something released over the weekend for people to play with - it’s far from done, but some parts are working reasonably well… We can then have a think about how to combine the two UIs, or maybe leave them separate…

Chris

[Karel Goderis]

+1 indeed. very slick indeed

On 11 Dec 2014, at 20:14, Ben Jones <ben.j...@gmail.com> wrote:

Just wow Chris - that new UI looks fantastic. God knows how you find the time to do all this incredible work!!

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/a01ab03f-b541-4326-ad9d-627d00b2c2f0%40googlegroups.com.

[Kai Kreuzer]

I share your feeling. But I´m not sure if this can be prohibited. I guess Paper UI and Chris UI will not be the last tries to come up with a UI for openHAB. But I agree that it would be better for the user to bundle our energy into one good application, than having two applications, which have a lot of common functionalities.

I don’t want to prohibit people from implementing UIs. But I only want to have one „official“ AngularJS-Bootsrap-HTML5-UI as a part of the openHAB 2 runtime.

And having more than one developer working on this UI would be perfect, both in terms of quality of the architecture and long-term maintenance. I am aware that collaboration adds additional burdon and one can be faster to do things on ones own. Nonetheless I think the benefits outweigh these problems. 

So much from a purely project management perspective and what I think is best for the evolution of openHAB and its community.

Even if Chris would make his UI white, they look completely different and they have different conceptional design and usability. So in that case I think it will not be a good experience for the user if we would integrate all kinds of applications into one UI. For that we could better use the dashboard as entry point into different apps.

I do not really agree that using the dashboard is the solution. If I imagine, that both Paper UI and HABmin further evolve and Paper UI has a great inbox handling, while HABmin brings me the best way to configure my ZWave network. What options do I have? Install two phone-gapped apps on my phone? Both polling for the same events all the time in the background? I’d rather want to have a single app, where I can switch between the different functionalities in the main menu. Clearly the break in the look&feel is everything but nice, but what to do about it? At least I would stay inside the same smartphone app (where the menu becomes your „dashboard“)  and all the technical infrastructure would be shared (e.g. authentication settings, background events, etc.).

Regards,

Kai

Am Donnerstag, 11. Dezember 2014 21:38:32 UTC+1 schrieb Chris Jackson:

Hi Kai,

The nice thing about using Bootstrap as the UI framework (on top of Angular as the application framework) is it works fine with touch as well - and it's responsive. However, the layout with the charting (with the list on the left and graph on the right) isn't ideal for smaller screens as it folds so the list is above and the chart below (at least on the phone - it's fine on the tablet). It works pretty well on my Android phone, and my tablet (and of course the PC). It does need a bit more styling for these devices to make the layout a bit nicer (maybe hiding some buttons when the screen gets smaller), but it works reasonably well given I've not made a lot of effort to on this yet...

I'm guessing the Paper UI is likely to be the same - it's the way of the world these days - people don't really want to design multiple UIs, it should just work on whatever device. On the other hand,from the user perspective, people have different likes and dislikes when it comes to UIs, so I'm not sure if there's a one size fits all anyway (??)

I'll see if I can get a working version of this available over the weekend to play with...

Chris

-- 
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/e2871cd6-4394-4d48-9831-a8289682ed02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/be96097f-ae5d-4173-a83e-de36ef0f8b8a%40googlegroups.com.

[Daniel Abegglen]

Kai, you are right, but if html5, please support IE, specially since for WP are no other (webkit)browsers available.

Regards,

Daniel

Am Freitag, 12. Dezember 2014 10:24:53 UTC+1 schrieb Kai Kreuzer

[Chris Jackson]

I do not really agree that using the dashboard is the solution. If I imagine, that both Paper UI and HABmin further evolve and Paper UI has a great inbox handling, while HABmin brings me the best way to configure my ZWave network. What options do I have? Install two phone-gapped apps on my phone? Both polling for the same events all the time in the background? I’d rather want to have a single app, where I can switch between the different functionalities in the main menu. Clearly the break in the look&feel is everything but nice, but what to do about it? At least I would stay inside the same smartphone app (where the menu becomes your „dashboard“)  and all the technical infrastructure would be shared (e.g. authentication settings, background events, etc.).

Hi Kai,

The original intention with HABmin wasn't to make it ZWave specific - it was meant to be a generic interface for configuring and administering anything in openhab. The interfaces were designed to be generic, but as the configuration interfaces weren't something that was deemed appropriate for OH1, HABmin wasn't integrated into openhab, and other bindings didn't pick up the interface. The client side though was written from the start to be completely independant of the binding. Currently there is support in HABmin for configuring the basic configation for other bindings though, so I really don't consider HABmin a zwave interface.

The intention for the new HABmin was to integrate it with OH2 and have it as a full admin and UI provider - which I think is what we discussed offline a few months back. So, again, the intention isn't to have HABmin as a zwave interface, and moving forward with OH2 I would want to make sure that whatever interfaces are used to configure zwave, are part of the core, and not part of the zwave binding. We already discussed this within the scope of the configuration stuff a while ago (ie the need for 'dynamic' configuration). I'm not sure if this is added already as at the time I think it was decided not to do it yet. If this sort of interface is added, then zwave, and other 'complex' bindings can use this and for sure HABmin will support any binding using the interface. 

Cheers

Chris

[Kai Kreuzer]

Hi Chris,

I didn’t want to say that HABmin is Z-Wave-specific, I just wanted to give an example where one UI might be better suited for one functionality and the other for another.

I understand that you are also targeting a universal UI for ESH/OH2 and that this was triggered by our discussion around https://bugs.eclipse.org/bugs/show_bug.cgi?id=440012. But the idea at that time was already to have a look at Material Design and if this can be an option (possibly through Polymer) for the new UI. As there wasn’t any visible progress from your end, Dennis started with the Paper UI (and I assigned the issue to him as a „public sign“) since we needed something for testing the new configuration REST APIs.

Wrt „dynamic“ configuration, I assume that you are right and the current UIs won’t suffice to cover all your use cases. This is something I would hope we can further evolve when migrating the Z-Wave binding and I learn about the concrete problems that need to be solved.

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/bd15fd88-ce9e-46b5-b011-4a5ab7240068%40googlegroups.com.

[Chris Jackson]

Hi Kai,
To be honest, I have not seen this bug - or at least not followed it, so I didn’t know other stuff was going on. I was simply working following our offline discussions on this (!).

Anyway, while a little frustrating for all I’m sure, the history is largely irrelevant - the question is more about how, or if, to combine these efforts. My feeling is that this is difficult from looking at the different architectures (as I think Dennis already pointed out).

Chris

[Dennis Nobel]

Hi Chris,

maybe for a start, you can have a look at my angular services definition file (see https://github.com/dnobel/openhab2/blob/paper-ui/bundles/ui/org.openhab.ui.paperui/web/js/services.js). I´m using the resource plugin for the REST access in angular-js. And I think at least this part can be reused in all angular-js based applications for openHAB or Eclipse SmartHome. 

You asked about the possibility for dynamic configuration. It is already added, this is what the whole thing concept is about (see https://github.com/eclipse/smarthome/blob/master/docs/sources/architecture/index.md#things and https://github.com/eclipse/smarthome/blob/master/docs/sources/architecture/configuration.md#xml-structure-for-configuration-descriptions). While developing Paper UI, I added a lot of the needed REST interfaces for it. It is not yet documented, but we are working on this. But from the service definition file, I think you can see how the REST interfaces look like. Moreover in the upcoming weeks the config description will get a lot of enhancements for a more specific declaration of configuration parameters. The REST interface will be extended, too.

However, Paper UI makes use of the new Thing APIs only. So it is not possible to use it for an existing z-wave or any other OH1 binding. I´m not sure if we need an intermediate solution for it, until most of the bindings are ported to the new APIs.

Does it makes sense to have a chat or make a call together with Kai and discuss the actual situation and see how we can work together?

Regards

Dennis

[Chris Jackson]

Hi Dennis,
Thanks for the info - I’ll take a look at the services, and I’m sure that there’s reuse of libraries that’s possible. I was thinking more along the lines of reuse of the UI and ‘framework’ which might be difficult to combine the two…

I’m happy to have a chat, or Skype or whatever - that probably makes a lot of sense (email isn’t the best for ‘chatty’ type things…).

I’m also happy to start looking at porting zwave over to OH2 and start using the new APIs for configuration - that will give it a good test and we’ll be able to see if there’s something missing :) I will try and look at this over the Christmas break - or maybe before if I can get some time, but work is a bit busy at the moment :(

Let me know when and how suits for a chat…

Cheers
Chris

[Chris Jackson]

I updated the screenshots etc and added an install ZIP on the HABmin 2 site (https://github.com/cdjackson/HABmin2) last night. Note that this still needs the HABmin JAR from the HABmin 1 site.

It's still pretty raw, but it gives something to play with.

Chris

[Dominic Lerbs]

Hello,

any updates if the Z-Wave binding is working with openHAB2?
From your post I'd assume it is not working. However, there was somebody mentioning on the openHAB1 forum or bug tracker that the binding works with openHAB2 (which is why Kai updated the compatibility matrix).

I have tried to install the binding on openHAB2 but I am seeing some errors/warnings.
Now I'd like to know if it is worth investigating these errors and the problem is in my configuration or if the binding generally doesn't work with OH2. :-)

Thanks,
Dominic

[Chris Jackson]

I haven’t looked at this yet as I was hoping to try and get the major refactoring done first. While the binding might work under OH2, it won’t work properly as the folder structure for OH2 is different. This will mean that some things won’t work at all (e.g. naming your nodes) and things like initialisation will be slow. There needs to be some ‘bodge code’ added to detect which version it’s running under and perform some file operations using the different structures...

What errors are you getting?

Chris

[Dominic Lerbs]

Wow that was fast! Thanks for the reply.
Here is a summary of my errors, if you are interested in the complete debug log I could provide this also.

20:49:31.088 [INFO ] [.z.internal.ZWaveActiveBinding:306  ] - Update config, port = /dev/ttyACM0
20:49:31.109 [INFO ] [.service.AbstractActiveService:169  ] - ZWave Refresh Service has been started
20:49:31.117 [DEBUG] [.z.internal.ZWaveActiveBinding:99   ] - Zwave Network isn't ready yet!
20:49:31.428 [INFO ] [b.z.i.protocol.ZWaveController:142  ] - Starting Z-Wave controller
20:49:31.451 [INFO ] [b.z.i.protocol.ZWaveController:147  ] - Z-Wave timeout is set to 5000ms.
20:49:31.462 [INFO ] [b.z.i.protocol.ZWaveController:376  ] - Connecting to serial port /dev/ttyACM0
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyACM0
20:49:32.982 [DEBUG] [eController$ZWaveReceiveThread:1189 ] - Starting Z-Wave receive thread
20:49:33.036 [INFO ] [b.z.i.protocol.ZWaveController:389  ] - Serial port is initialized
20:49:33.068 [DEBUG] [WaveController$ZWaveSendThread:1042 ] - Starting Z-Wave send thread

20:49:50.384 [ERROR] [eController$ZWaveReceiveThread:1252 ] - Message cancelled by controller (CAN), resending

20:49:51.393 [WARN ] [z.i.p.i.ZWaveNodeStageAdvancer:71   ] - NODE 6: Already in or beyond node stage, ignoring. current = Ping Node, requested = Ping Node

20:51:39.007 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.014 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.024 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.030 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.036 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Humidity, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.042 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Humidity, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.051 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.058 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.064 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Humidity, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.071 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Humidity, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.078 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Battery, command class name = battery, using 0 refresh interval.
20:51:39.084 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Battery, command class name = battery, using 0 refresh interval.
20:51:39.092 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.098 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Temperature, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.104 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Humidity, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.111 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Humidity, command class name = sensor_multilevel, using 0 refresh interval.
20:51:39.118 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Battery, command class name = battery, using 0 refresh interval.
20:51:39.124 [WARN ] [.b.z.i.c.ZWaveConverterHandler:244  ] - No command class found for item = Aeon_CO_Battery, command class name = battery, using 0 refresh interval.

Interesting part is that I cannot use the zwave binding in OH1 anymore after I had started OH2:
OH1 log:
2015-01-29 20:59:41.777 [INFO ] [b.z.i.protocol.ZWaveController] - Connecting to serial port /dev/ttyACM0
2015-01-29 20:59:42.587 [ERROR] [b.z.i.protocol.ZWaveController] - Port /dev/ttyACM0 does not exist
2015-01-29 20:59:46.046 [INFO ] [.service.AbstractActiveService] - ZWave Refresh Service has been shut down

I suspect this is the culprit (from the OH2 log)?: RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyACM0

After a reboot of my raspberryPi it works again fine with OH1.

[Dominic Lerbs]

Ah I just realized... I am starting OH2 as root while I am starting OH1 as user 'openhab'. Maybe that's why RXTX is able to remove the lock file...?

[Chris Jackson]

I suspect you’re right - it certainly looks like a problem with permissions (there have been a lot of threads on serial port permissions recently) rather than a problem with the binding.

Chris