Custom integration with custom heating system

Configuration
1

So getting back to the original plan I had, before I started playing with HA and other things.

Integration with my heating system. It’s “head less” in that it has no UIs, except graph output. There is current no integration to change target temps, I will be adding that.

I would like a way to change the target temperatures used by it from a UI. HA seems a realistic candidate so I don’t have to develop one myself.

So what I have is a small set of profiles. Minimum, Eco, Prefered and Maximum.

Each has a target temperature for each particular zone. Currently “living room”, “bedroom”, “office”, “garage”.

If I am in the house it will most likely be in “preferred” profile. The use case I have is:

“It’s a bit chilly tonight, I think I’ll turn the heating up a bit” (for whatever irrelevant reason I choose) and I would have an ability on a dash board to select “Living Room” and “Preferred” and increase it from maybe 19 to 21.

I don’t mind if I have to have one widget for each zone and profile as I will most likely only be changing one or two of them frequently. If I need to change the anti-freeze setting in the garage that would be a rare event and I don’t need a UI for that.

That would cause a message/request to be sent to a thing which would update the target temperatures and the system would respond accordingly.

I think REST is probably the best mechanism to do this over and a request might be:

POST (or PATCH if you are a REST pedant)
http://thing/temperatures/preferred/livingroom
{ “target”: “21” }

Obviously for retrieving the temps for display, there would be a complimentary GET
http://thing/temperatures/preferred/livingroom
Sending back: {“target”:“19”}

I know there are RESTful sensor and RESTful switch, but I’m not sure either seem appropriate. So I’m not that afraid to try and write a custom integration if there is an example or template one to work from.

Does a REST thing exist that can be attached to a slider or a + and - button?

2

Look under Home Assistant Integrations key word ‘rest’. You will see several components, sensor, switch, command, etc. I’m sure you can cobble something together to do what you want with them without too much work.

3

Thanks. A quick browse this morning and I think I can do something with a combination of:

Input number

And rest command/automation:

Potentially falling back to shell command if I have issues with the rest automation, as per:

4

I will stand by the fact that MQTT outshines in this area.

5

Okay, I’ll bite. Explain your analysis that makes you believe this.

EDIT:
Feeling it a bit unfair a little trolly of me I will give you a hint.

REST is a application communications framework, not a protocol. It traditionally uses HTTP as it’s transport application layer protocol.

MQTT is a transport protocol, not an application protocol. So unlike REST it does not define anything about how you would use it.

If you look at what they stand for, it will give you a hint in how they are intended to be used:

MQTT = Message Queue Telemetry Transport.
REST = Representational state transfer.

There is even the option of implementing REST over MQTT. This is because they are not “peers” in the protocol stack. They occur at different layers. In this sense, MQTT is peered with HTTP, not REST.

6

what (I think) @flamingm0e is saying is that usually MQTT is used by many types of IoT devices. REST is not that usual. I could think about some “pros” of using MQTT instead of REST, like the publisher/subscriber model. But use whatever you want :-).

7

This.

This is condescending AF…

I really don’t need you to explain that to me. I have been using MQTT for projects for over 4 years.

It doesn’t require any api on the device to receive the call. It’s merely a pub/sub. There is no need for an http “server” to run on the device which means it’s more battery efficient, and less power hungry, also doesn’t need the overhead that http requires (what little there is). I also don’t have to know the IP or hostname of the device. MQTT broker handles all the information I need.

This doesn’t make any sense, but as @clyra said, “use whatever you want”. I just think MQTT is better for iot type devices.

8

Which is great if you want a pub/sub model :slight_smile:

I get it that most of the user base of the home automation space have bought a thing and another thing and have a bunch of things and they come to HA et al. to bind them all together. I’m not really coming at it from that point of view. I am coming at it from the point of view of being one of the people making those things.

When you come to choose a protocol or communications mechanism you choose it based on your requirements and the merits, pros and cons of each. As an example, my “probes” and “sensors” send UDP packets. The main reason for this is that a sensor can do exactly nothing if the receiver is not ready or not present or doesn’t receive the message for some reason. There is literally nothing it can do. So UDP is the preferred protocol as it does not require the receiver to even exist. It’s lightweight, fire and forget, best effort and does not cause locked up, timing out connections if I was to use any protocol built on top of TCP, like for example MQTT.

When you come to things that you DO want a response from, to form a kind of transaction based interaction then HTTP/REST et al are preferable. If you look at (excuse me for saying) the mess that MQTT causes with HA’s MQTT switches you will see what I mean. The model they use there is an pessimistic rollback transaction, which is far from ideal. It asks a thing to do a thing and hopes it will receive a non-coupled state message on the topic at some time later, if it doesn’t get one within a few seconds it reverts the state back, basically it has no idea what the real state is now. I get it, for MQTT that’s about the best you can do as it’s not a transactional transport, nor is any message bus/queue system. However a REST request or any transaction based request response that isn’t an issue. You can guarantee a few things, such as responding with the actual state after the operation has taken place. The only holes in the transaction are when the connection dies, disconnects or resets after you send the request. You can handle this in the receiver, if the connection terminates unexpectedly and you can’t inform the sender of the state, you revert the state.

I’m not slagging HA or MQTT, they have their purpose and they do their best, but what I am seeing is people just jumping on one protocol or other because that’s the thing they already have or just because other people are using it. Or more likely because don’t really have a choice, because they have devices which require it.

I will be using MQTT where appropriate or where I have no choice. The Pub/Sub model has one distinct advantage over request/response and that is it supports multi-receiver, multi-sender and can form a message bus, which REST/HTTP etc can’t really do without intermediaries, proxies and relays.

9

The MQTT library is your API. You need to maintain an open and active, long lived connection to the broker. You need to handle connection state, reconnections, resubscriptions, dead connections, timeouts, keep alives…

Do not confuse simplicity with having something done for you.

10

So am I…

or it’s something I have built dozens of sensors and devices around for over 4 years…

I’m not. But what I can tell you is that I am done discussing anything with you.

11

To be honest this works for me too :slight_smile: