Single Flow/Logics App for Homey/Domoticz and others

Ideas & Suggestions
1

Due to the removal of the Desktop programming interface;

I have been thinking about this issue for some time now. I also have tried Domoticz. All systems have their pros and cons. But the way you can program them is fixed. Homey has only flows, Domoticz has other kind of programming. But switching to another platform cannot be done without reprogramming it all.

Therefore I have decided to start an Open Source project that should overcome this. This project will be an (ASP.NET Core) application (running on Linux/Mac/Windows) where you can add (virtual) devices, program in many ways (flows, javascript node-red etc. and call http(s) request to activate devices.

With this application you can easily switch between Homey, Domotics and other platforms. The only thing you need to do is:
On the new app:

  • create (virtual) devices
  • create flows or whatever way you want to program the logics
  • call http when device should change (like light on)

On Homey/Domoticz

  • add devices (Hue lights etc)
  • on device changes call http request to new app
  • handle requests from new app (e.g. light on)

This way, you are less dependent on the hardware and/or driver app (Homey/Domoticz)
If you switch, you only have to create the devices, program http requests on changes you are interested in and act on http request. But further no logics.

The advantage is not only that you are less dependent on the choise of hardware, but you can also add more interfaces (node-red, or whatever), combine hardware platforms.
Also, no dependency on the API of the platform you use

Today I will start with this project.
The (asp.net core) app should contain at least the following:

  • ability to create device types (light, light with color, weather station etc.)
  • device (type) has input (status) tags and output (for handling incomming http requests and outgoing http requests)
  • ability to create programs/flows (the logic)
  • swagger OpenAPI
  • backup/restore / import/export

A lot still needs to sink in and will probably be defined along the way. But in the future I don’t want to get stuck with one type of device, just because I need to program everything again if I want to change.
Also, I want to use both, Homey and Domoticz as a hardware/plugin layer, but all combines in one programming/flow interface.

3 Likes
2

Interesting idea :slight_smile:

I would probably consider something more persistent than HTTP connections, though. Websockets, MQTT, something like that.

3

Good point!
I thought about http requests due to the fact that most devices (Homey/Domoticz) are capable of sending and receiving data this way.
But you are right that this is not the most efficient way as means of communication. SignalR (websockets), MQTT might be better if available.

The fact that you mention this, let me think of the idea to have multiple posibilities for communication.
So the app should not only contain the http option, but also the MQTT option.
Websockets might be a trickier one, because you need to write an app for Homey and Domoticz. I don’t know if you can do this for Fibaro Center?

But to have different options is a good idea.

4

MQTT Hub/Gateway guess you have seen this.

1 Like
5

Thanks for pointing this out. Not only that there is a Homey app for this, but also that people have problems with it.
Seems the core bussiness of Athom.

You should only need the apps needed for the devices Hue (bridge) app, Fibaro z-wave app for devices, but besides that as less apps as possible.
The whole idea of the new application is that you can easily switch between platforms (Homey, Domoticz or others). If you rely on MQTT app from Homey, you might end up with a buggy system while it is not needed at all. Besides, other systems might not have aMQTT option.

That being said, the new application should at least make it possible.

6

Robert … I read your reply on the MQTT-Hub thread

MQTT Hub maintains all the topics within the homie3 branch in realtime … so they are absolutely bang up to date including state. No need to use ‘broadcast’

7

HarriedeGroot already answered in the other thread.
It is a bug in the MQTT Hub. It has been fixed in a branch and I have to wait for this new update I think.
The Homey client will broadcast all states after connecting.

8

Yes - it used to work fine and then something subtle glitched it but now it’s apparently working again in the HA branch - which you can load into Homey via CLI if you wish. I’m about to do that myself.

9

I will press ‘BROADCAST’ for now :wink:

OK, this means that the first target of this new app won’t be http requests, but MQTT.
I have checked some systems and MQTT is more wide spread than I thought it was and it seems a good starting point.
Later I will add the fact that you can create devives with properties and capabilities yourself and on how they get updated (http requests)

For now I focus on MQTT because I can easily automate it.

10

It maybe that ‘broadcast’ still isn’t updating state but does update all the other properties, but if you do already have state info in onoff and dim for example then you’re good to go.

MQTT is increasingly supported in most HA applications but there is no real standard way of representing devices / capabilities e.g. a level could be 0.0 - 1.0 or 0 - 100 or 1 - 256 or anything. homie3 is the best attempt so far but still needs work, and HA have their own discovery protocol for MQTT. So getting MQTT devices into HA applications and controller is still awkward. It requires mapping of the topics and massaging of the data. Often nodeRED is used for this.

I see your app as trying to minimise such work and look forward to seeing it evolve. There is definitely a need for such an app I feel. However nodeRED seems an ideal candidate to work with as you have a lot of similarities and available addins. Installed via Docker very easily. You may even be able to use the nodeRED Dashboard as your main front end for a visually simplistic interface. It’s a ton of work on your own.

Kevin