REST API to control the app

@WEHA Have you successfully linked your MQTT topic to a Label?

That’s the only thing you should be trying to do right now. We need to take this 1 step at a time.

Please share your HRP. I can be of much better help if I can actually see what I’m working with. Just be sure to remove any sensitive information like passwords.

The Imperihome Local API documentation is no longer available online from their sites which are now dead.

Just saw this Youtube video however about it.

Thanks for sharing. I suppose this is something that could be added in the future.

@WEHA Attached is a very simple working example I put together for you. When the MQTT variable Switch_Raw turns on, it opens a page AlertPage.xaml.

MqttClient_Scene.hrp (8.1 KB)

Imperihome does indeed run a local webserver where you can control certain aspects like the ones in my OP
If I can get MQTT working I can accomplish the same.
But for some things it’s way easier to just post / put / get an http url.
MQTT requires running / using a broker while HTTP calls can be called from many devices / software (Like Doorbird / BlueIris)

So I tried your file:

  • changed the ip address to my mqtt broker
  • changed the SubscribeTopic to the one I’m using
  • changed the trigger content in the scene from “true” to “back” (as in back camera)
    After pressing play and triggering the payload, nothing happens.
    I have a mqtt client on my phone and the trigger is received so the MQTT broker is working.
  • changed the DataTriggers from true & false to back & front
  • changed the eventriggers to the same
    After pressing play, the switch does not change state

There is no log from what I can tell so I have no I idea what is going wrong.

When you send the payload, does your Label show the new value you sent?

Again, the 1st thing you need to do is verify the app is reading your MQTT topic correctly. If it doesn’t show your “back” in your Label, it’s not going to trigger the scene.

Realize too this is based on state changes. If your topic is always showing “back”, it’s never going to trigger the scene. You’ll need to reset it back to some other value once you’ve handled the event.

For all practical purposes you can delete those other controls on that page. The ONLY control you should care about is the Label. DataTriggers & EventTriggers are irrelevant & not necessary.

Attached is a new project with that other stuff removed because I think it was confusing you.
MqttClient_Scene_v2.hrp (4.1 KB)

Well, I really meant nothing, so no, the label does not change :frowning:
Only state change? Well than this is useless to me I’m afraid.
It needs to do something regardless if it’s the same payload.
If I can reset the state myself with a script after like 30 seconds, that could be a solution.

I take that back. I don’t think it’s dependent on state change. If you start the app & that value is set it will trigger the scene.

Does the Label show “back” or “front” when you start the app?

Can you share a screenshot or video capture of it? I really want to see it just so I know for certain it is reading the topic from your MQTT server.

And please post your project. You probably have a minor mistake that I can spot somewhere in your scene configuration. There isn’t a lot that needs to be done for this to work & I feel like I’ve shared everything you need to know. If your project is using a 192.168.X.X address nobody else can access it. It’s a private IP. The only thing you should remove is a password if you are using one. I don’t need that.

There is currently no ssl/tls nor auth required for the broker.
So the file attached is how I ran it.

MqttClient_Scene_v2.hrp (4.1 KB)

Notice the Label on that screenshot is blank. That means it’s not reading the topic.

Close & reopen MQTT Explorer. There is a known issue with them showing cached values. I suspect your Trigger is no longer “back”. When you publish a payload be sure to set the retain option. Otherwise Home Remote may never see it.

@bill
This line of thinking opens up new ideas, but they may depart from the original architecture and philosophy of HR. Just wild spitballing from here forward:
HR is only designed as a UI, and it doesn’t run its own hub. It is somewhat agnostic of a hub and in some uses there isn’t a hub at all.
That also means each HR device is agnostic of other HR devices on the same network.
For some uses it would be useful to have a central HR hub in the network somewhere, but that would be a completely different ballgame. A separate machine in the network? what OS? maybe a plugin for the most common home automation hubs in the market?
A REST API would be very useful, but it opens new questions: does it go directly to the device running HR? If there are more than one… which one? Or how to address them all? Could separate instances of HR communicate among them and exchange data in a hubless mesh?
Could a single HR file know which tablet is running on, and have conditional clauses depending on a ‘device id’ variable? For example show different things if the tablet has an id of ‘kitchen’ or ‘livingroom’?

Feel free to ignore my ramblings… :laughing:

I’m not sure why you would think this has to do with MQTT explorer.
The plugin, my android app and MQTT explorer all correctly receive the payload.
What you see in the screenshot is not cache but a fresh one, it is also the first time I ever opened the application and there was no cache.
The only thing that does not work unfortunately is the MQTT device in The Home Remote.

Anyway, I tried with retain enabled, same thing.
Now I tried changing the topic and it turns out it does not require a leading slash like yours did.
So after removing that it finally worked…
Is this because there are brokers that require a leading slash?

I deducted a scene from your project and I seem to be able to get it to open de device details.
I added a delay and close details but I will test those out later.

EDIT: thank you for the assistance :slight_smile:

@torontonian you would access the rest api via the ip address of the device, HTTP is not a bus or broadcast protocol.
This would require setting a static ip on the device or setting a static DHCP lease.

I am certainly open to adding to adding a REST API. The 1st version would most likely be for a specific instance. You’d have to assign a static IP to your tablet as @cw-kid says here.

That would be the simplest approach. Perhaps down the road it could expand to “mesh” network you suggest.

Because that Label isn’t showing anything. If it was working & the Label would be displaying “back”. Use a remotely accessible server so I can help you troubleshoot. Use “test.mosquitto.org” temporarily. Once we get that working for you then you can switch to your private one.

I am still testing Home Remote and tweaking the dashboard app that integrates with my Vera hub, with a view for Home Remote to eventually replace the Imperihome app I have on all our phones and wall mounted tablets.

With the Imperihome HTTP API it is enabled and I have set a static IP address on my router for each wall mounted tablet.

If I want a particular tablet and Imperihome app to go to a certain dashboard page for exmaple, I send a HTTP command from Vera to that particular tablets IP address.

If I want all tablets to show an IP cameras stream for example, I would send multiple HTTP commands from Vera to each tablet to display that camera etc.

You probably did not read the whole post, the error was in your project.

Probably not. Move the part were you say it is working to the top of your post:)

From your 1st sentence I’d have to assume it’s not. Sorry, I get a ton of emails & messages in a day. I tend to skim through things fast sometimes.

Does the topic you publish to include a slash?

If it doesn’t, then you’d need to exclude it. I just tested that 1st example I shared with the slash & it works too.

MqttClient_NoSlash.hrp (8.1 KB)

I don’t think there are any brokers that require a leading slash. That was just carried over from the old example I shared in the Google Group a few years ago. I don’t remember my reasoning for including slashes on those topics.