meatpiHQ / wican-fw

GNU General Public License v3.0
288 stars 54 forks source link

[REQUEST] Official "WiCAN integration for Home Assistant" from MeatPi Electronics? #194

Open Hedda opened 1 week ago

Hedda commented 1 week ago

Note! This is a follow-up to https://github.com/meatpiHQ/wican-fw/issues/3 (which should be moved to discussions as only suggestion for Home Assistant community to do it).

This a formal request for an official "WiCAN integration for Home Assistant" (via a "custom component") from MeatPi Electronics.

@meatpiHQ please consider creating and maintaining an official "WiCAN integration for Home Assistant" from MeatPi Electronics.

Maybe you can consider adding development of a MeatPi official dedicated Home Assistant integration for WiCAN (native "custom component" for Home Assistant) as a stretch goal to represent it as a further funding milestone in your ongoing crowdfunding campaign for the WiCAN PRO on Crowd Supply as that could help spread the news and get more Home Assistant users interested in buying the WiCAN hardware (and get more developers interested in contributing to the firmware)? Regardless, having an dedicated custom integration for Home Assistant is probably the best way to reach a higher adoption rate and have more people follow the news what is going on with updates for this project.

The reason for this request is that while it is great that the WiCAN firmware update has improved support for Home Assistant that way of directly using MQTT via Home Assistant is still too advanced for beginners (or users with limited time) and I do not think that is simple enough to use by the broader userbase of mainstream Home Assistant end-users, and what is missing and would be needed to target that mainstream userbase is a have a more streamlined setup for using WiCAN with Home Assistant, and in essense means having a dedicated "Home Assistant integration" (also refered to as "custom component" by developers) and for that WiCAN integration to present each WiCAN adapter as a "device" and then each endpoint attribute on that device as an "entity" ("entities") + if services are available; a set of actions that can include triggers, conditions, and actions that can be used and triggered in Home Assistant automations.

So if Home Assistant users are a part of your targeted market audience then should should look into and try to prioritize developing an official "Home Assistant integration" for WiCAN, an integration that under the hood makes use of MQTT or other available APIs and presents them as native "entities" ("entity") via that WiCAN integration. I believe having even just a minimum WiCAN integration will help get the word out:

One of the main use cases with Home Assistant integrations is protocol and dependency abstraction, so from an end-users point-of-view they do not need to know or care what APIs that integration is using to communicate with the WiCAN firmware, so in practice the end-users will not need to know that it depends on MQTT (as Home Assistant configuration flow will automatically initiate the installation and setup of an MQTT broker in Home Assistant if the user do not already have one configured).

You as the developer of the integration can choose what endpoints should be used and which attributes of what endpoint should be exposed and presented as native Home Assistant "entities" ("entity") via that WiCAN integration which can be trigged in automations via actions. You can also use templating and templates inside the integration to have it present more advanced features:

I would recommend that you start by creating a simple WiCAN integration as a "custom component" for Home Assistant and get that published via HACS (Home Assistant Community Store) to get more eyes on it before you begin to look at getting it into the Home Assistant core (as integration components that are included there and ships with Home Assistant core by default have higher requirements). Recommend that you check out these additional links on the topic of creating a custom component for Home Assistant (note that they are a little older so might not be fully up to date with the latest Home Assistant development standard and structure), where many of them contain infromation on how-to write a custom component integration that commuicate with MQTT:

The purpose of having a ready-made integration for WiCAN would be to make it easy for anyone to install/configure and get started and that would really be the best way to get more Home Assistant users interested in the WiCAN hardware and firmware project. The fact is that many (if not most) Home Assistant beginners will first search Home Assistant integrations page (which only includes integration components built-into Home Assistant core), and more experienced Home Assistant end-users will extend that search to also include HACS (Home Assistant Community Store for integrations shared by community developers there but not included yet as built-in Home Assistant core integration components), and you can expect most only buy a product if it already has a ready-made integration on one of those because otherwise it is often simply to much work for normal end-users to maintain and update it.

By the way, check out this new blog post which explain what is new in HACS 2.0 (which made it easier to install community integrations)

PS: If and when you become a Home Assistant custom integration developer and want to learn about changes and new features available for your integration, be sure to also keep following news via the Home Assistant’s developer blog:

Hedda commented 1 week ago

As also mentioned in -> https://github.com/meatpiHQ/wican-fw/issues/3

Suggest that you as well check out Home Assistant's existing integrations (custom components) that are MQTT-based and present different device types and services as actions which can be triggered. So you can make a new dedicated Home Assistant integration custom component that utilize your existing MQTT support and expose/present relevant functions/features as makee that new dedicated WiCAN integration work as a kind of generic "Car/Truck OBD and CAN Bus" custom integration by having that Home Assistant integration act like a virtual "hub" (also referred to as bridge or gateway) for that in turn makes use of all different existing MQTT integrations under the hood and make the WiCAN Can Bus adapter duplicate and abstract relevant MQTT topics and subscriptions to show them as kind of "hub" that present one of multiple "devices" that expose endpoint attributes as "entities" with different support "device types" (example "sensor", "binary sensor", etc.), as well as "events" for momentary things, to Home Assistant:

https://www.home-assistant.io/integrations/#hub

See example existing integrations "Velbus", "Modbus", and "OpenTherm Gateway" integrations which all acts as a "hub" integration (hubs == gateways/bridges with APIs, meaning they can abstract multiple devices which they, in turn, can present to Home Assistant in a uniformed matter to Home Assistant), as well as the "MQTT Alarm Control Panel" which is an "alarm" category integration:

https://www.home-assistant.io/integrations/manual_mqtt/ https://www.home-assistant.io/integrations/velbus/ https://www.home-assistant.io/integrations/modbus/ https://www.home-assistant.io/integrations/opentherm_gw/ https://www.home-assistant.io/integrations/supla/ https://www.home-assistant.io/integrations/thethingsnetwork/

Anyway, there are loads of MQTT integrations which in turn can be used indirectly from other integrations as dependencies:

https://www.home-assistant.io/integrations/#search/mqtt https://www.home-assistant.io/integrations/mqtt/ https://www.home-assistant.io/integrations/mqtt_eventstream/ https://www.home-assistant.io/integrations/mqtt_statestream/ https://www.home-assistant.io/integrations/binary_sensor.mqtt/ https://www.home-assistant.io/integrations/sensor.mqtt/ https://www.home-assistant.io/integrations/device_trigger.mqtt/ https://www.home-assistant.io/integrations/number.mqtt/ https://www.home-assistant.io/integrations/select.mqtt/ https://www.home-assistant.io/integrations/button.mqtt/ https://www.home-assistant.io/integrations/switch.mqtt/ https://www.home-assistant.io/integrations/light.mqtt/ https://www.home-assistant.io/integrations/scene.mqtt/ https://www.home-assistant.io/integrations/lock.mqtt/ https://www.home-assistant.io/integrations/alarm_control_panel.mqtt/ https://www.home-assistant.io/integrations/siren.mqtt/ https://www.home-assistant.io/integrations/fan.mqtt/ https://www.home-assistant.io/integrations/climate.mqtt/ https://www.home-assistant.io/integrations/device_tracker.mqtt/ https://www.home-assistant.io/integrations/mqtt_json/

Also check out other "helper", "utility", and "automation" integrations that they have which you can make use of in integrations:

https://www.home-assistant.io/integrations/#helper https://www.home-assistant.io/integrations/#utility https://www.home-assistant.io/integrations/#automation

It would also be a nice feature to include the export integration diagnostics for troubleshooting the integration for HA, see:

https://www.home-assistant.io/integrations/diagnostics/

Hedda commented 1 week ago

Oh, and if you @meatpiHQ would consider this then perhaps add a link to this request under your features wishlist for tracking:

...or create a roadmap under the "Projects" (Kanban board) section in this GitHub repository for better tracking (and transparency):

meatpiHQ commented 1 week ago

@Hedda I’m planning to create a custom component for WiCAN, especially now that I want to support ESPNetLink as a GPS tracker and LTE gateway for WiCAN PRO. This custom component will include options for an MQTT bridge to connect to public MQTT brokers, along with full integration of WiCAN functionality. Additionally, I want to include support for HTTP and webhooks, which will simplify things even further.

MQTT via Home Assistant is still too advanced for beginners (or users with limited time), and I don’t think it’s simple enough for the broader Home Assistant userbase.

I’m aware of this, which is why I’m focusing on making it as user-friendly as possible by utilizing automation and car profiles. The firmware development is largely driven by the Home Assistant user base, and that’s where this project is headed.

I’ve looked into examples of custom component integration, and there’s still a lot for me to learn. It’s going to take some time to get everything working because I’m juggling hardware, firmware, and production. However, I think I can start with something basic and gradually build on it.

Hedda commented 1 week ago

I’ve looked into examples of custom component integration, and there’s still a lot for me to learn. It’s going to take some time to get everything working because I’m juggling hardware, firmware, and production. However, I think I can start with something basic and gradually build on it.

That sounds great! It is my belief that as long as you can provide something that at least meets your own idea of what a first-release of an ”official” custom WiCAN integration for Home Assistant would look like with just some bare-minimum features and function to serve as a basic MVP (Minimal Viable Product), then that will be something than you yourself and the community can togethwr build more on later.

I do not believe that there should be any need to set the bar too high on an initial (pre-alpha/alpha/beta) version, but instead make it a simple proof-of-concept with a goal of having it easy install by using a config flow that works all through the UI pf Home Assistant.

I think that plug-and-play UI installation in Home Assistant should be the ultimate goal though, but that does not need to be in the first-release.

typxxi commented 1 week ago

Can't agree more.

Europe is becoming the next big EV market and that is a key market for the WiCan dongle which works, but that was a challenging adventure and people would not buy it if I tell them that I had needed 100 hours or more cause the e-GOLF has not been done before and everything was different than many recommandations which referred to e-GOLF is like an e-Up.

But the market is growing fast especially for all those used cars which had been sold new as company car and are now bought by private owners who want to get rid of VW cloud and all the other manufacturers.

It feels somehow that the current average driver and non it guy is not your target group considering the small amount of master templates that would work. You need a lot and deep knowledge to get start.

I am happy but my father asked if I am crazy and why it takes so much time.

If you have such integration than try to get someone on board to speak about it like Andy from the channel off grid garage. He is famous to push manufacturers to develope & engineer good products, he is an australian resident, he welcomes his viewers (100.000 subscribers) welcom to sunny hot australia. We have 22Ampere ... and shows the sunny sky or clouds.

He does diy solar power systems and batteries, then charging evs and what not.

He is a german emigrant and I guess you should get allong quite well cause even the chinese are cooperating with him. Search for "off grid garage". His audience is the usual diy guys and therefore the key audience or evs and charging and then of cause meatpi wican dongles, not the usual garage or workshop.

Good luck.

Hedda commented 1 week ago

If you have such integration than try to get someone on board to speak about it like Andy from the channel off grid garage. He is famous to push manufacturers to develope & engineer good products, he is an australian resident, he welcomes his viewers (100.000 subscribers) welcom to sunny hot australia.

@meatpiHQ FYI, Phil Hawthorne who co-hosts the Home Assistant Podcast (as a hobby while actually being a professionell web developer) is also an Australian, so maybe once you released an initial pre-alpha version of a WiCAN integration for Home Assistant then you could also contract him and ask what car/cars/truck/trucks he owns so can create profiles for his vehicles and then get him to test a prototype or pre-release unit of the upcoming WiCAN Pro in the hopes of getting a interview spot on the Home Assistant podcast where can do a shameless promition for it ;) He is on GitHub at @philhawthorne however I guess that you can probably easist reach him via the Home Assistant podcast contact channels:

https://hasspodcast.io

https://bio.link/phil

https://philhawthorne.com

https://github.com/philhawthorne

https://kit.co/philhawthorne

https://twitter.com/philhawthorne

https://www.greataustralianpods.com/home-assistant/