That’s a neat idea to simply use the configuration possibilities that are available.
My only concern is how you want to handle evolution? I assume you might need changes to the structure from time to time and old versions will thus be incompatible. You should at least leave that open for yourself in the early development phase, so that you do not introduce to many workarounds just to keep backward compatibility of the format.
Hi!
To be honest the goal here at this stage was to have simple, non-binding storage for the time being, while the model is still simple - basically, 3 levels of arrays (panel, dashboard, widget) with a flat list of properties varying from widget type to widget type.
That way, the app still “owns” the model, and may introduce some temporary, ad-hoc migration code for early adopters, who should be aware that breaking changes are still possible anyways 
As I see it, it will probably gravitate towards what would be the new sitemap model exposed by its own API… from my “newbie” point of view I’m thinking of something with a few common properties describing the binding to an item or directly to a thing/channel, the formatting of the value, then a dictionary allowing “vendor-specific” properties à la CSS - in my case, the position/size in the grid and the cosmetics.
I’m stil struggling to see what the migration path from the current DSL-defined sitemaps would look like though… but I’ll move this discussion to the ESH forum thread you mentioned in your other post 
Absolutely, that was also my assumption - I do not want to interfere with your definitions at all here right now. I was only referring to the app evolution of the model, which might mean that users lose their definitions when they upgrade to a more recent snapshot.
I think it makes sense that you work on this independently for now, get your experiences what works and what doesn’t and we can then together revive the new sitemap discussion at ESH, but this isn’t anything urgent. And I actually do not foresee any compatibility with DSL-defined sitemaps; I don’t think we will need any migration path for them.
What is the preferred way to update to the latest version?
I had originally had the zip file extracted to conf/html and it worked fine.
Then I downloaded the .jar file to addons once you released the server side saving and it worked fine.
Then I updated openhab to the latest and deleted the conf/html contents for Panel UI.
Now I can no longer save to the server. I see this when I go into advanced:
[quote=“Kai, post:23, topic:12981, full:true”]
I was only referring to the app evolution of the model, which might mean that users lose their definitions when they upgrade to a more recent snapshot.[/quote]
For now there have been only additions to the model, no breaking changes - when that happens I’ll be sure to handle it properly, and maybe add some version number to the JSON object.
[quote=“Kai, post:23, topic:12981, full:true”]
I think it makes sense that you work on this independently for now, get your experiences what works and what doesn’t and we can then together revive the new sitemap discussion at ESH, but this isn’t anything urgent. [/quote]
Ok, I’ll do my own thing until I reach a more stabilized state and we’ll see how we can work from there then
Whoa, I honestly don’t know what happened there 
Can you go have a look at the JSON object in the service configuration dialog area in Paper UI, the big text area, verify it has not been erased? Thanks.
It was empty. I had saved the JSON from the browser I was using and pasted it in there but that didn’t work. Is there a different format for what is preserved there vs in the browser > advanced settings > show local configuration object?
Thanks!!
Ah, don’t know why it has been emptied. Good thing you still have your local configuration, simply type
{}
in Paper UI to make sure the server property is properly initialized, then go into the app settings, switch to local storage, paste your local configuration into the “show local configuration object” text box, and finally click on the “save the current configuration to a new panel configuration” link and give it a name.
1 Like
Wow, that was easy! Server config is stored.
I do, however, get this when I try to save any changes:
Server save failed! Panel configuration has a newer version on the server updated on 2016-08-17T16:03:06.612Z
The save is made to the server though.
Yes, sorry for the concurrency check snafu… It was actually saved the second time I just committed a fix. You can pull it to your clone in conf/html if you have one; I’ll made another .jar, probably this weekend.
2 Likes
New snapshot up on GitHub:
https://github.com/ghys/openhab2-addons/releases/tag/panelui-2.0.0-20160822
Notably includes (apart from a few fixes, like proper formatting for numerical values) 2 new widget types, Knob and Chart - including fancy new (experimental) interactive charts consuming openHAB 2’s persistence API endpoint!
Obligatory shout out to the libraries used for these:
2 Likes
Excellent, very nice work. The charting is very nice indeed. At this rate i’m going to be moving from my BasicUI setup to HabPanel sooner than I thought.
One comment, when using the server provided format you might like to also disable the HabPanel Unit or it gets duplicated. I’m not sure if there are cases where you would want to add another unit though, so perhaps best to leave as-is.
shrug
Those are really nice additions to the application!
Thank you!!
What is the best way to install and maintain the most recent version. Between the .jar file and the html files I am not sure what to update when. thanks!
Install the .JARs when they’re out, especially when there are server-side changes, and use that if you’re happy with a relatively stable version; clone the git repository into conf/html if you see changes in the commit logs you absolutely want and can’t wait for a new .JAR.
1 Like
What is the correct syntax to use in the format field on the dummy widget for date & time.
Following is what I currently get for “sunrise”, which is the same as the Basic UI after the first screen refresh.
Ideally, I just want to display… 07:10
Thanks,
Mike
A little code change is needed so DateTime items are parsed properly, like Paper UI. Can’t make it now, probably in a few days. Can you open an issue on GitHub so it’s tracked properly? Thanks
Hi,
thanks for your excellent work.
Finally there is an UI that is simple, usable, customizable and NICE!
I am testing under OH1 and I couldn’t understand two things:
-
how do you automatically refresh the items status?
In my installation the widgets do not get refreshed when the status of the item is changed from somewhere else. -
what should I write in the “COMMAND VALUE” field of a button to turn it “on” and “off” when the button is pressed.
Can you share an example?
Finally are you planning to introduce a Color Picker widget?
That would be awesome.
thanks again
Nice nice, this is the right way! is it possible to install on openhab 2 like habmin/paer UI in the initial menu?
Sorry,
found on https://github.com/ghys/openhab2-addons/releases/tag/panelui-2.0.0-SNAPSHOT
when you have time there is the installation path to change