spacemanspiff2007 / HABApp

Easy home automation with MQTT and/or openHAB
Apache License 2.0
54 stars 23 forks source link

Odd question: Is openHAB required? #378

Closed magnuslsjoberg closed 1 year ago

magnuslsjoberg commented 1 year ago

OK, I admit that this is a really odd question, but I have over time moved more and more over to HABApp and I have replaced all my bindings with python modules or bash scripts (easier to maintain, and I can tweak them if needed), items are created on the fly by HABApp rules and I have only one openHAB rule left to send notification to my phone.

So, I currently use openHAB for the eventbus and the items I create, but can I rely on the HABApp eventbus and HABApp items instead? I guess that there is a lot going on under the hood in openHAB so it may be a lot I have missed in my thinking...

spacemanspiff2007 commented 1 year ago

Yes - openHAB is completely optional. You can use mqtt to connect other external devices instead. Obviously you have to replace the openHAB items with HABApp items.

However what you'll most likely be missing is a gui that shows the item values and allows you to interact with your system.

NickWaterton commented 1 year ago

have only one openHAB rule left to send notification to my phone.

I have a HABapp rule that sends notifications to my phone, so I have no OpenHab rules at all.

Bite the bullet! Get rid of that last rule.

magnuslsjoberg commented 1 year ago

@NickWaterton

Thanks for the encouragement Nick!

No openHAB rules is one thing, but what about items and event bus? I haven't investigated, but I thought that HABApp was driven by the openHAB event bus. (I hope I'm wrong!)

Either way, I will continue to look into this since I found HABApp very robust but have strange things going on with openHAB, even though I have installed from scratch a few times, changed SD-card, changed from RPi 3 to 4, ... I have also moved influx, grafana and my flask-app for the GUI to the old RPi 3.

Some follow-up questions:

magnuslsjoberg commented 1 year ago

@spacemanspiff2007

Ooops! Sorry, I missed your reply before I answered to Nick...

I already have my own GUI as a flask-app. Can I subscribe to the HABApp event stream (SSE)? I use MQTT for som sensors and add more things there.

Thanks both for the support!

NickWaterton commented 1 year ago

I use Prowl https://www.prowlapp.com/apps.php and pyprowl https://pypi.org/project/pyprowl/ to send notifications to my iPhone.

Been using it for years, works with no issues.

spacemanspiff2007 commented 1 year ago
  • Do you only create HABApp items and rely on the HABApp event bus?

  • I currently run openHABian, what is your OS?

  • What are you using to send notifications to your phone? (iPhone in my case)

I have a mixture of openHAB and HABApp items. My HABApp instance runs on Ubuntu Minimal. I'm using pushover for the few notifications I am sending, but I think there are countless providers.

Can I subscribe to the HABApp event stream (SSE)?

Currently HABApp does not provide a SSE interface. However it should be very easy to inject a thin wrapper around the HABApp event bus which sends the events over web socket.

magnuslsjoberg commented 1 year ago

I have started my migration to HABApp "Item" and "MqttItem" and I can clean up a lot by skipping openHAB items in most places and I can also simplify the flask GUI app by subscribing directly to MQTT messages.

However, I don't quite understand MqttItem... It seems like the name of the item must be the same as the full topic. It that how it is supposed to be?

I.e. If I have the topic 'home/sensors' the item name must be 'home/sensors/myItemName' Would it be possible to have both a name and a topic? item = MqttItem.get_create_item('OutdoorTemp',topic='home/sensors') or possible: item.publish(topic,payload)

Another thing that could be nice is if DimmerItem, SwitchItem and so on existed for HABApp item and MqttItems as well. Perhaps even being able to have one HABApp item that could post/publish to both openHAB and MQTT like: dimmer = DimmerItem.get_create_item('MyDimmer') dimmer.post_value(value) # HABApp dimmer.oh_post_value(value) # openHAB dimmer.mqtt_publish(value) # MQTT

To be honest, this may just be something I miss right now, because I have to change all my DimmerItem, Switch, Number,.. to plain "Item".

spacemanspiff2007 commented 1 year ago

It seems like the name of the item must be the same as the full topic. It that how it is supposed to be?

Yes - that's how it's supposed to be. What would be the benefit for another item name?

Have you already completed your transition?

magnuslsjoberg commented 1 year ago

Well, to have shorter item names instead of the complete topic path…I did however implement it in another way!For each item I model, I already had a class, eg class LightModel(HABApp.Rule). There I created openHAB items for each property (_Brightness, _Color). Now I reuse that class but creates 2 MQTT topics (hue_lights/status/ and hue_lights/control/)I then send a JSON-formatted dictionary to these topics. Reading status updates from the Hue bridge are published on the status topic, and events from automation or GUI are published on the control topic that the item is listening on and in turn control the Hue bridge.Similar setup for other items.The GUI app listens on MQTT for status and publish on the control topic.It all works very well, except that status information only is available if you happened to listen at that time. I haven’t looked into this but may implement some “get all states” in my flask app, that would query the states. The best thing is that the response time from tapping a control until status is updated in the GUI is much faster now. With openHAB in between that could take a second or two, now its almost instant.It also means faster response to switch on a light!On 9 May 2023, at 12:39, spacemanspiff2007 @.***> wrote:

It seems like the name of the item must be the same as the full topic. It that how it is supposed to be?

Yes - that's how it's supposed to be. What would be the benefit for another item name? Have you already completed your transition?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>