Example of PUB messages required to display/trigger Android app?

[jpmens]

For debugging, it may be useful to document an example of a set of messages which will make the Android app do something ... ;-)

[binarybucks]

Uh yes, thats probably not that obvious when you're not using it since half a year ;)

Actually, when you have components that publish some messages according to the conventions in https://github.com/binarybucks/homA/wiki/Interfaces you will have something to play with.

When you just have a broker up and running, would that be sufficient for the sake of seeing something?

• Define a control: /devices/Testdevice1/controls/Testcontrol1/meta/type:switch
• Set control value /devices/Testdevice1/controls/Testcontrol1:1
• Define a second control /devices/Testdevice1/controls/Testcontrol2/meta/type:Text
• Set second control value /devices/Testdevice1/controls/Testcontrol2:Some text
• Define a control for a second device: /devices/Testdevice2/controls/Testcontrol1/meta/type:switch
• Define control value /devices/Testdevice2/controls/Testcontrol1:1
• Set custom name for second device /devices/Testdevice2/meta/name:This is a custom name

When you flip a control, the value is published back to /devices/$deviceId/controls/$controlID/on

Does this meet the definition of "doing something"? If so, I'd put it into a readme so it becomes easier to find.

[jpmens]

Thank you. I think I'm almost there, but not quite:

pub="mosquitto_pub -h hippo -r "

${pub} -t /devices/FAN1/controls/Testcontrol1/meta/type -m switch
${pub} -t /devices/FAN1/controls/Testcontrol1 -m 1

${pub} -t /devices/FAN1/controls/Testcontrol2/meta/type -m Text
${pub} -t /devices/FAN1/controls/Testcontrol2 -m "Room ventilator"



${pub} -t /devices/Testdevice2/controls/Testcontrol1/meta/type -m switch
${pub} -t /devices/Testdevice2/controls/Testcontrol1 -m 1

${pub} -t /devices/Testdevice2/meta/name -m "This is a custom name"

I do indeed see "FAN1" in the app. Tapping on it shows Testcontrol1 (with a switch), and Testcontrol2 with text "Room ventilator".

I run a `mosquitto_sub -t '/devices/#' . When I flick the switch On/Off/On/Off, I see

/devices/FAN1/controls/Testcontrol1/on 0
/devices/FAN1/controls/Testcontrol1/on 0
/devices/FAN1/controls/Testcontrol1/on 0
/devices/FAN1/controls/Testcontrol1/on 0

Must leave now. Will test later.

[binarybucks]

I guess you want to toggle the status of FAN1-Testcontrol1?

In that case something (ideally the thing that subscribes to /devices/FAN1/controls/Testcontrol1/on to physically switch the physical device on and off) has to publish the value back to /devices/FAN1/controls/Testcontrol1 (note the missing /on).

What happens is:

• The interface just sees /devices/FAN1/controls/Testcontrol1 which you set to 1.
• When you press the button that publishes the opposite value (0) to /devices/FAN1/controls/Testcontrol1/on for your device to react
• Now nothing happens to the value, and for the interface it still looks like /devices/FAN1/controls/Testcontrol1 is 0
• The next time you're still lost in step 2 and so on

The internal state of that control in the interface is only set to 1 when something echos back the published 1 from /devices/FAN1/controls/Testcontrol1/on to /devices/FAN1/controls/Testcontrol1 to which the interface is subscribed.

The reason for this is described in https://github.com/binarybucks/homA/wiki/Interfaces#topics : "The reason for this is to prevent any interface or actor from receiving an echo of their own publish and to just display a changed value if it has been handled successfully by an actor."

During development we discovered some nasty side-effects such as infinite publish loops when controls set the same values to which they are subscribed, thus the two topics for each control.

[jpmens]

Sounds obvious, @binarybucks, thank you.

Another question: will/does the Android app have the ability to show the switch statuses on the main page? I'm thinking along the lines of

FAN1                                On
Ventilator                          Off
Whatever                          Off

etc. :-)

[binarybucks]

I'd really like that and it has been suggested somewhere in the depths of the Google+ Android Design community, but:

• Realizing that with Android's ListViews seems to be quite a pain
• That would require the power control to always be uniquely identifiable (it would have to have a defined name, or preferably a special meta attribute).

I opened the improvement issue #98 for it, in case I got some free time or someone would like to work on it ;-)

[binarybucks]

Issue for demo component is now at #100, Android App Card design is now at #98, so I'm closing that one.