Premise [download] JQM

[chucklyons]

123  - let me check = the original custom .js file w84 created works well. I may have loaded the one I had commented out due to the Yahoo weather dependency. I'll upload the original custom.js. BTW, glad to see you're still around!
 
W84 deserves the credit - he started a great UI.
 
doczaius - not sure whether to say thank you, I agree, or something else. As you said, JQM is simply js and CSS. It just makes it simpler for hackers like me to use... .I have the UI done for the AB that looks like the new MB UI, I'll prob just upload the AB version first, then upload the MB version after I get some of the annoyances worked out..

 

[123]

Thanks, Chuck! I'll wait for the latest and greatest version from you.

I've been tinkering with openHAB. It's written in Java and runs on Windows/MacOS/Linux. It shares Premise's concept of binding virtual objects to real devices. However, its vitual objects are less complex. It's like if in Premise you were to bind properties individually (temperature, arming status, etc) and not whole objects (Thermostat, SecuritySystem, etc) It's both an advantage (granularity, flexibility) and disadvantage (a mountain of setup work).

Whereas Premise's UI is auto-generated from Home objects, you manually declare what will appear in openHAB's UI. However, you can define a bunch of different UI's (one for you, one for the kids, another for guests, etc) and invoke the one you want in the URL. openHAB has a pure browser interface (looks like an iPhone; for webkit-based browsers only) as well as clients for iPhone and Android.

Big roadblock for me is the lack of UPB support and an ELK M1 driver (a DSC driver is available ... as a starting point to write a new ELK M1 driver). Nor does it have a driver for an X10 CM11A (I still use X10 for a few things) but there are some workarounds. Someone is working on a UPB driver but it is still in beta (maybe alpha). There's a steep learning curve for developing a new driver (Java, the Eclipse IDE, openHAB's driver architecture, GitHub, etc).

Compared to Premise, some things in openHAB are incredibly easy (acquiring and consuming XML or JSON data is oh so much easier than in Premise) and others are jaw-droppingly hard (No scenes. No calendar-like scheduler. A driver can't update the list of devices discovered, etc).

Rules are written in a Java-like language but, with a few tweaks, it also supports Python (specifically, Jython). FWIW, it's based on open standards (Eclipse SmartHome, Maven, Karaf, etc) and has a very active community. https://community.openhab.org/
 

Perhaps of some interest to you might be Project Rotini. This is one person's attempt to create a completely new Android interface. I like its aethetics and the ease of defining UI's.
https://github.com/igorgladkov/rotini/wiki

For example, here is how you'd display an on/off fan control using a Switch widget:

Frame label="Bedroom Fan {widget:switch,icon:fan}" {
Switch item=Fan_Bedroom
}
Cocoontech seems to dislike displaying PNG files so you'll have to click to see it: https://github.com/igorgladkov/rotini/wiki/images/widget-switch.png

"Fan_Bedroom" is defined in a separate openHAB file (it defines the binding between "Fan_Bedroom" and the physical device). Far easier than anything in AutomationBrowser or MiniBrowser!

Another example using the Gauge widget:

Frame label="Humidity {widget:gauge}" {
Text item=Sensor_Bathroom_Humidity label="{unit:%,icon:water}"
}
https://github.com/igorgladkov/rotini/wiki/images/widget-gauge-1.png


There's a long thread on the openHAB forum for Project Rotini. https://community.openhab.org/t/different-take-on-client-ui-android-for-now/3561

Here are a few screenshots of a sample "Rotini" UI. Crisp, clean, informative, easy to understand and navigate.

 

[w84no1]

I was testing openHAB and found Home Assistant(https://home-assistant.io). I like HA a little better as it has an update every two weeks and it supports more of my devices out of the box. It is Python based, so a little easier for me than Java. Unfortunately I have moved away from Premise.

 

[etc6849]

123,
 
Good to see you have your Premise server up and running again.  So are you going to stick with OpenHAB or come back to Premise?
 
I've been busy with other stuff and haven't tried JQM yet.  Hopefully you and Chuck can get together and post a final version of JQM for me to use
 

Kudos to Chuck, W84no1, and all others involved in creating JQM. Looks great!
 
I installed it on a test server and it displays all (well, most) of the items in the Apartment model. Unfortunately, I must've goofed somewhere because nothing actually works. If I turn on a light in the browser, no matching action occurs in Builder. If I turn on a light in Builder, nothing is updated in the browser. As a sanity check, http://localhost/ip works fine.
 
 

 
Can anyone shed light on what could be causing it to fail?
 
FWIW, I tested it with Edge and Internet Explorer 11 on Win10. I assume JQM is browser agnostic? I've been experimenting with openHAB and it requires a webkit-based browser.
https://community.openhab.org/t/openhab-crashes-non-webkit-browsers-normal/10006

 

[123]

I'm still running Premise; looking to get JQM running.
 
For the moment, I'm just exploring openHAB. I've read and tinkered with the 1.X stuff and will now move to 2.0 which adds significant improvements (and breaking changes).
 
FWIW, Premise's object model remains superior. Premise's Builder reveals more information in a clearer manner than openHAB's Designer. However, openHAB is evolving whereas Premise is static. Eventually it will become difficult to interface with things. You can't find useful COM objects anymore to help extend the functionality of Premise's VBScript language. Now you're obliged to rely on external programs to talk via UDP, consume JSON, etc.
 
Anyhow, I have a lot of time and effort invested in Premise; re-inventing openHAB drivers for the ELK, the Omnistat RC2000, etc are not high on my to-do list! All I need right now is a better UI for non-Windows devices and JQM appears to be it. openHAB is just for 'intellectual curiosity'.

 

[123]

I downloaded w84no1's original "Custom.js" (posted by Chuck) and that corrected the problem I mentioned above (browser UI failed to display device's correct state).
 
Upon further exploration, my use of the word "corrected" appears to be limited to the two browsers installed on my laptop, namely Microsoft Edge and Internet Explorer. When I displayed JQM in Safari on an iPhone running iOS 8.4.1, things weren't so rosy. The "ON/OFF" switch widget continually toggles between its two states! With no action on my part, the browser UI shows the switch flipping (about once a second) between on and off.
 
Anyone else seen this quirk?
 
The goal of this exercise was to allow my wife to use her iPhone to control lighting and, boom, it doesn't work precisely where it's needed (obviously some form of Murphy's Law is at work).

 

[w84no1]

I never had that issue, but I was using an older version of jqm. I was using an old iPhone 3g for testing.

Like Chuck said, if you drop back a version or two, it might fix that.

 

[123]

There are four files ending with 1.3.1:

1. jquery.mobile.structure-1.3.1.min
2. jquery.mobile.theme-1.3.1.min
3. jquery.mobile-1.3.1
4. jquery.mobile-1.3.1.min

I replaced them all with version 1.4.5 and this eliminated the self-toggling "ON/OFF" widget on Safari (running on an iPhone 4s, and an iPad Mini, provisioned with iOS 8.4.1).
 
I know nothing about jQuery Mobile but why does the folder contain jquery.mobile-X.X.X.min and jquery.mobile-X.X.X. Is one not just a minimized version of the other?

 

[w84no1]

Yes, they are just minimized versions and should be used for speed. The other file is just there so you can see the source.

 

[123]

Nope. I was wrong. Now it's happening in Edge as well.

1. Stopped Premise Server service.
2. Replaced all version 1.3.1 CSS and JavaScript files with 1.4.5 files ( in ./Premise/SYS/web/css and js)
3. Updated all references to 1.4.5 in  gMBRenderHeaderEx()
4. Restarted Premise Server service.

No joy. Self-toggling switch widgets are back.
 
Looks like I'll have to learn how this actually works in order to debug it. Phooey.

 

[123]

Icons were no longer displayed after upgrading to 1.4.5.
 
Searched their forum and discovered 1.4.5 references icons differently than 1.3.1. The old version grouped the icons in a single file whereas the new one breaks them out into individual files. Alternately, you can pick a CSS file where icons are already included as opposed to referenced externally (or versions where SVG and/or PNG icons are included).
http://forum.jquery.com/topic/newbie-jquery-mobile-1-4-icons
 
I deleted the multiple references to 1.4.5 in gMBRenderHeaderEx() and replaced them with a single one to jquery.mobile-1.4.5.min.css (203 Kb; includes everything).

Icons are back but self-toggling switch is still a problem.

FWIW, the rendering function for Fans has an error. It uses an undeclared reference to "oItem". Example: Run "Status" in the UI on the Apartment model and the debugger halts on the offending line when it attempts to get status for a bathroom fan.

 

[123]

Progress!
 
I replaced the polling functions in custom.js with the ones in Chuck's version. Goodbye self-toggling switch widgets!
 
Next step is to replace the entire custom.js file (sourced from the Downloads section) with Chuck's version and see if the original problem returns (i.e. non-functional switches and sliders).
 
 
FWIW, I'd like to see a version of jQuery MiniBrowser without reliance on AutomationBrowser and minus all the cruft to support ancient browsers (running on long-dead devices). The resulting module would be smaller and simpler than MiniBrowser.

 

[123]

Search MiniBrowser.xdo for "Automation". I get 13 hits. Minibrowser uses portions of the AutomationBrowser module in:

• mbGetImage
• mbGetLocationEx
• mbGetCaption
• gMbRenderHeader
• CustomPanelButtons
• MediaShortcuts

In other words, MiniBrowser can't stand alone, it requires AutomationBrowser. I don't foresee a future for AutomationBrowser because of its reliance on ActiveX. It'd be nice to have a standalone Minibrowser module.
 
Yes, crufty code designed to support bog-standard HTML browsers like on the Audrey, WindowsCE devices, and other relics of the past. When I revised MiniBrowser a few years ago, I included hooks to support an "advanced UI". You folks ran with it and created something much better than the original. I think MiniBrowser should be the "advanced UI" with no code to grandfather old browsers and devices. It doesn't need properties to control the UI's color scheme. It doesn't need the refresh() function nor methods like mbUp(). I don't think there's an overwhelming need to support CustomPanelButtons. Strip this deadwood out and the resulting module would be easier to read and maintain.
 
Anyhoo, whenever you release the next version, I plan to delete the legacy code (and use this leaner version for my purposes). I'll also try to eliminate all references to AutomationBrowser. Then I'll make sure all GUIDs are different so it is no longer a derivation of MiniBrowser (i.e. importing it won't trounce an existing instance of MiniBrowser).
 
Looking forward to the release of your revised MB.

 

[etc6849]

Please post your leaner version   I want to test that my Android webview app will work with it.  I can't remember if it relied on the refresh() method, but I do need to recompile it so HTTPS can be used too...
 

Anyhoo, whenever you release the next version, I plan to delete the legacy code (and use this leaner version for my purposes). I'll also try to eliminate all references to AutomationBrowser. Then I'll make sure all GUIDs are different so it is no longer a derivation of MiniBrowser (i.e. importing it won't trounce an existing instance of MiniBrowser).

 

[123]

My suggestion was more along the lines of creating a new Module based exclusively on the JQM portion of MiniBrowser with no legacy code and no reliance on functions in AutomationBrowser.
 
For discussion purposes, let's call this hypothetical Module "PremiseBrowser" (I know, not an original name but bear with me). PB would work standalone, without the AB and MB modules installed. If someone needed to support ancient devices, they could load AB and MB. You could have all three, AB, MB, and PB, peacefully coexist.
 
To achieve this, PB would have to be a brand new Module created from scratch. Forgive me, I imagine you already know this but it's important to mention it (to avoid swearing and hair-pulling later on). You can't just delete the legacy code out of an existing copy of MB and rename the Module to PB. All its objects would still have the same GUIDs as in MiniBrowser. Importing it into Premise would corrupt an existing installation of the MiniBrowser module (the two Modules would fuse into one unholy mess, like Seth Brundle in Cronenberg's "The Fly"). You'd need to create a fresh new Module and copy-paste the classes from MB to PB (the action of copy-pasting within Builder automatically generates new GUIDs).