Feature request "meta/unit"

[hmueller01]

Hi,

I'd like to have a unit on some of my shown topics. For the moment I add the unit when I publish the topic (like 23.0 °C). But this breaks other features (e.g. if I like to write the topic to a database using a decimal field).

Would it be a good idea to add a new meta topic like /devices/<systemId>/controls/<controlId>/meta/unit and to add this after the payload when shown on the front end? If not available, no unit is shown so the feature is backward compatible anyway. This will also reduce traffic (a little bit ...) for topics updated very often. :)

I would be happy if someone of the HomA crew comments this. If agreed I am willing to add code for this feature.

Thanks Holger

[stylpen]

I think it is a great idea to have units displayed on the interfaces and agree with you that .../meta/unit is the best way to add it without breaking anything. It should be fairly simple to support it in the web interface but I'm not quite sure about the android app. Nobody has touched it for a while ...

[hmueller01]

I had some trouble getting the app compiled using the (old) Eclipse SDK. After getting the needed libs and some tuning I managed to get it (almost) work. I just had to comment out the Bugsnag calls (in App.java). This won't work at all (app crashed after launch).

The change was VERY simple. Just an additional call in view/ControlView.java setContent() method: setContent(c.getName(), c.getValue() + c.getMeta("unit", ""));

But I realized the the github app version is 1.6.00, while the Google play version is 1.6.01. Are there any relevant changes? Should I issue a pull request based on the "old" version?

Right now I have not setup the web interface. Is someone else able to add the unit feature to the web interface?

Holger

[binarybucks]

Tbh. I'm not sure what the difference is to the .01 version. Before doing any changes one would have to move the whole code to Android Studio

[hmueller01]

Ok. I imported the code to Android Studio and tried to update the dependencies to the latest versions (still commented Bugsnag, really needed?). This updates eventbus to 2.4.1 (3.0.0 changes too much and eventbus 2 may still be used as greenrobot says). But with this new version a deprecated call to register() in ServiceBackgroundPublish is removed: EventBus.getDefault().register(this, Events.StateChanged.ServiceMqtt.class); I replaced this with EventBus.getDefault().register(this); which seems to work. But I am not sure because I never worked with eventbus and do not know the use of the passed eventType ...

Another question. Is it purpose that the MQTT subscription is not stopped if the app is "destroyed" (exit app with back button)? On the Android Monitor (in Android Studio) I still see messages, but the task manager does not list the app ...

[binarybucks]

You can completely remove everything related to Bugsnag. It is/was a crash reporting library that is no longer required.

The new register method should work as it registers to all types then.

The background service and the MQTT connection should stay active as long as the ongoing notification is shown even if the app is exited.

[hmueller01]

Unfortunately Android Studio changes the whole file structure completely. Would it be a good idea the use a separate repository for the android interface (e.g. homA-android) like @simonvanderveldt suggested in his issue #137? This makes it much easier to check out and in from Android Studio directly ...

IMHO the background service should check if on mobile or WiFi connection. My broker sends data every second and that costs me a lot of traffic (of my very limited bandwith) over the day.

[hmueller01]

@binarybucks: I have created a new repository homA-android and checked in the latest code for use in Android Studio. If you like I can transfer the ownership to you.