Hi.
I can't find if there is a chance to build server style of drivers to be able to listen ports and respond on network requests to HE.
There are some applications like Link to Hub/Hub link that seems are able to do that.
Is this Server API closed?
Have you looked at the Maker API app?
This gives you the ability to control devices etc via http calls from external devices/apps etc
It depends exactly what you want to do.
Andy
I'm talking about building something like http server, not just access to devices.
Maker API - is just a proxy...
It would also be great (TCP and UDP) for sending a global message to find local devices that are not UPNP. It would, of course, have a time-out variable and a close command. To find devices now, I have to send a request to all 254 possible device addresses on the network with Many Errors.
2 Likes
Port 39501 is where you direct incoming HTTP messages to the hub from your device. The device ID must be one of three things, i know one is the MAC. The other two escape me right now but if you have a device sending info to the hub that the hub doesn't know what to do with, you will see an entry in the logs with the three ways that device is being identified by the Hub. Then the message is automatically parsed to the correct device in your hub. This is the basis of the Hubduino project. This is how all those sensor inputs are passed back to Hubitat from your ESP board. This is also how @ericm's tasmota firmware passes the switch state back to the hub.
How to make HE listening on 1883 for accepting TCP with any message structure?
1883? Who uses 1883? Hubitat is open to receiving HTTP messages on 39501. If you want an idea of the structure of the message, take a look at the hubduino library. There is a whole library that @ogiewon built but in the end, the message is parsed by the driver. So it's really up to you.
1883 - usually it's a mqtt protocol devices.
What?!? Devices talk to the broker which talk to hubitat. And unless i am mistaken, that all happens on port 80. You aren't specifying a special port in your hubitat MQTT driver, are you?
Why don't you take a look at the hubduino libraries....or ask @ogiewon. He can probably tell you more. I just know you have to use port 39501 for unsolicited http messages to the hub. That's why ericm and ogiewon use it in their device firmware. I know that the Hubduino drivers use a custom port for outbound messages...but that is not the same as inbound messages.
If you were trying to implement a broker on HE, or a minimalistic broker lookalike then wanting to use port 1883 would be desirable. I don’t think it’s possible though.
Although having a broker on HE would be tidy I personally don’t think it’s a good thing to do, for performance reasons. Although HE has probably enough CPU oomph it can become I/O constrained.
I guess broker is the less loading thing we could ever imagine. For the personal home automation even if you would ever have 500 devices - it would be nothing in terms of load on CPU.
There is a lightweight mqtt broker written in Java, which is 1.5Mb size for the sources...
I bet it is possible to convert it to groovy
MQTT broker is a hub software. Having additional Orange PI or Raspberry PI just for the broker sounds tedious
You just have to convince Hubitat of this.
1 Like
Would be nice... I could potentially get rid of 3 node.js / Node-Red flows if Hubitat would just listen on a port for unsolicited messages.
To be fair, I use Node-Red for other things now, so shoving values in/out via MakerAPI isn't the end of the world for me, either.
1 Like
I think that's what @Ryan780 was saying with port 39501. As long as you aren't tied to a specific port with your application you could use port 39501 and have the parse method do your filtering. I plan to test this eventually just haven't had the time lately.
1 Like
Ah, you are right. I wasn't reading it that way originally. Interesting idea.
There are some scenarios where that might be possible, but more in which I can't change the port the broadcasting device uses.
Better than nothing, though!
Flexibility starts when there is a way to define any port from within HE to be able to integrate external devices via Port Listening....
If it really is a resource contention issue, then I wish they would make a Hubitat Elevation "PRO" model with more resources.
Although they have repeatedly said resources aren't the actual limit on the hub's capability. So who knows.
1 Like
Ok, I tried to restrain myself but I have to ask? Why would be a good idea that Hubitat allows to open up ports/functions at the OS level to allow "other software functions" to work on a hub that is intended for a certain function? Basically you are saying that I want to use your physical device and software you delivered to me for whatever I want. Isn't that exactly what a rPI is for?
I would be really surprised, but happy to be proven wrong, if you would ever receive such a function.
The way I see, and that is just my personal opinion and not meant as an attack on your opinion, from a product development and support perspective it would be very difficult to support something like this. What would be next? Being able to plugin any USB device and get low level access to the USB port to allow anyone to do what they want?
Maybe I am missing the point.... Which is absolutely possible.... But I would never try to fit my size 8.5 foot into size 7 shoe.... It's not fit for purpose.
1 Like
Exactly my point @dan.t! The hub is a hub, don't try to make it into something it's not. You can't buy a Winnebago and expect it to win the Daytona 500. They are both expensive vehicles but they aren't designed for the same purpose.
And as far as flexibility on the incoming port...if the message is unsolicited, i would think that the flexibility should really be on the sender and not the receiver. If the receiver has established a certain port for a certain reason, if the sending application wants to connect, it's the one that should be flexible. I just think that people know that other systems will just refuse to be flexible so they put the onus on Hubitat to be the one who should change. Rather than have a technical reason it's more a path of least resistance argument, which i understand but it doesn't really justify it.
I want to get rid of rPI devices
