Wishlist: status control

[jpmens]

Maybe a nice enhancement? A control that can take one of four values (0, 1, 2, 3) to display a Nagios/Icinga status as in

0 = green = OK
1 = yellow = WARNING
2 = red = CRITICAL
3 = grey? = UNKNOWN

Mock screen shot:

[binarybucks]

How would it look on android?

Mit freundlichen Grüßen / With kind regards
Alexander Rust
On 27 Jun 2013 17:53, "JP Mens" notifications@github.com wrote:

Maybe a nice enhancement? A control that can take one of four values (0,
1, 2, 3) to display a Nagios/Icinga status as in

0 = green = OK
1 = yellow = WARNING
2 = red = CRITICAL
3 = grey? = UNKNOWN

Mock screen shot:

[image: jmbp-639]https://f.cloud.github.com/assets/60706/716976/8cc88b56-df41-11e2-82cf-200c836bece7.jpg

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/116
.

[jpmens]

I can't judge that, because I don't know what UI capabilities there are there...
Maybe a LED or something similar?
Maybe possible with the "card" interface?

[binarybucks]

We just had a little chat about it during breakfast. Generally that functionality is quite specific and probably not very useful for a majority of users. But as HomA aims to be extensible it would be good if there was a more generic feature that allows such functionality to be implemented.

One suggestion we came up with was to add a /meta/style tag to the text control.
As the current content of the text control is currently not escaped, you could add some nasty styles inline directly but that of course looks awful in the Android App as it doesn't know anything about html or css. With a new meta tag that is (for now) ignored by the Android app interfaces that do not implement the tag would display a plain old text control with 0,1,2 or 3 as value. However, with some custom CSS applied from the /meta/style tag those values could be interpreted somehow to fit your needs.

One problem now is how the CSS would interpret the value to apply different styles. I guess there is some CSS3 magic to achieve this.

Would that be a viable alternative?

[jpmens]

While it pleases me you're considering this, the CSS thing sounds pretty messy to me, particularly since it won't, as you say, work on Android (or on iOS later, I assume).

Supposing your proposed "card" interface is implemented on Android, I'm assuming it would have the approximate appearance of the current Web interface? Are there other 'controls' possible then? If you can point me to some description of Android's GUI possibilities, I'll gladly look to see if I find something suitable, also in view of a possible future iOS implementation.

[binarybucks]

Theres an overview of intput controls at http://developer.android.com/guide/topics/ui/controls.html and general building blocks at http://developer.android.com/design/building-blocks/index.html.

The thing is, that I would happily implement controls that are generally useful but at the moment I think it would probably result in a feature creep when we'd start to add custom controls for edgy usecases that might also be satisfied with standard controls. Besides that, I agree with the CSS solution being pretty messy.

[stylpen]

The "right" way to introduce this kind of extension is to add a new control type (/meta/type = nagios for example). This means that all interfaces need to be aware of that and handle the new control type in the appropriate way.

In contrast to that, adding just a new meta attribute will not break interfaces (like the Android app) that are not aware of it. This requires the least effort to "hack" that functionality into the web interface. A little less messy may be not to add a /meta/style attribute to the control but something like /meta/class or /meta/CSSclass. The web interface could then add that class to the DOM element. This would be a generic way to let users influence the look of the web interface but requires changes to the css file of the interface. There could also be something like a user.css file where those additional styles can be placed in and which gets included in the main style sheet.
Of course, that approach can only add styling functionalities to the web interface but at least is doesn't require changes to the Android app or anything else.

[binarybucks]

@stylpen 's approach is certainly cleaner whereas the /meta/style approach would not require the use of an additional css file as everything would be stored in the MQTT tree, of course. As of now, I've not found a viable golden solution for this :/

[jpmens]

I'm just trying to shoehorn everything into homA and MQTT, that's all. ;)

[binarybucks]

Yes and that's awesome. The above was not meant to be criticism not to use homA for that, only the attempt to find an optimal solution how to fit everything into homA ;)

At the moment we're writing our bachelor thesis so bigger features might have to wait a bit. However that shouldn't stop us from discussing ideas. Just the implementation might take a little longer.

[jpmens]

Thanks guys. I've glanced at the possible Android controls, and can't think of something generic enough.

[binarybucks]

Just came to my mind. What about a generic "image" control that can display e.g. base64 encoded images? That one could be used for more elaborate usecases like displaying rudimentary charts, webcam images or little status color tiles.

Definately possible with the webinterface, probably somehow also in Android.

[jpmens]

Sounds like just what the doctor ordered. I didn't dare suggest that, even though the thought crossed my mind.

On Jul 2, 2013, at 17:20, Alexander Rust notifications@github.com wrote:

Just came to my mind. What about a generic "image" control that can display e.g. base64 encoded images? That one could be used for more elaborate usecases like displaying rudimentary charts, webcam images or little status color tiles.

Definately possible with the webinterface, probably somehow also in Android.

—
Reply to this email directly or view it on GitHub.

[binarybucks]

Mh, so the implementation for the webinterface turned out to be pretty trivial. However, while playing with it I noticed that Paho returns an unknown error for longer message payloads (such as a base64 encoded image), so that I was just able to get it working with a standard url source.

@jpmens could you try to reproduce that Paho fails with longer message payloads so I can file a bug for this? Just publish some value for a text control that is a bit longer (as I was on the plane I had somewhat limited debugging capabilities, but I guess the limit is some power of two > 128 byte)