Replies: 22 comments 1 reply
-
|
As also mentioned in -> #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/ 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 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 It would also be a nice feature to include the export integration diagnostics for troubleshooting the integration for HA, see: |
Beta Was this translation helpful? Give feedback.
-
|
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): |
Beta Was this translation helpful? Give feedback.
-
|
@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.
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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 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. Good luck. |
Beta Was this translation helpful? Give feedback.
-
@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://github.com/philhawthorne |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Closing this one off, as MeatPi said a few weeks ago I've got a HA integration, its mostly working, with a few bugs I want to get sorted out before we do a 1.0 release of it, and then can start adding some nice to have features. @Hedda would be great to get exposure on the HA Podcast, it could certently generate a lot of interest in the project, and hopefully sell a lot of the units for MeatPi. Though IMO I'd want the integration at least in 1.0, which really just means the basics are working and stable, and would probably be a good idea to also wait for the pro release, since thats not all that far off anyway. Though once thats done reaching out to him to see if hes interested would be a good idea |
Beta Was this translation helpful? Give feedback.
-
@philhawthorne have you preordered the upcoming WiCAN Pro? https://www.crowdsupply.com/meatpi-electronics/wican-pro |
Beta Was this translation helpful? Give feedback.
-
|
@Hedda I haven't. I've only had a brief read over this, and not sure how it checks back in to Home Assistant. Is it WiFi? Getting a data-only sim down under is pretty expensive per month, so unsure about it for me. But this does look very cool. Will have to see if my Aussie-Korean (Kia) even has an OBD port |
Beta Was this translation helpful? Give feedback.
-
|
Hey @philhawthorne I've done the HA integration for WiCAN Every car since early 2000's has an OBD Port, so your Kia probably does, unless its very old The regular WiCAN (not pro) doesn't have 4G, that's just going to be an optional extra, so yes the primary method is WiFi. Currently HA pings the WiCAN every 30 secs to pull data, would also like to support WiCAN pushing data to HA for 4G as well, but thats probably quite a while away, even just for firmware support before I even add it to the integration. The most common use case at the moment is people with EV's getting the battery level of the EV, so that charging can be automated to minimise charging costs, but make sure it always has enough charge, however lots and lots of data can be pulled out. Here's some HA use cases I've thought of and would like to do at some point
There's lots more data that can be gotten out of cars to do various alerts/automation', and some cars expose lots more data via the OBD port for other various automation's and alerts |
Beta Was this translation helpful? Give feedback.
-
|
Well that was easy to find! My car does indeed have an OBD port, but unfortunately its right behind the panel for the fuse box. So impossible to have anything plugged in (even an extension cable) and have the fuse box closed. Yuk. I would love all those sensors in HA. Very useful to have. Would find the fuel gauge handy in HA, and we're always leaving the car unlocked overnight, that would be a win. Just so annoying the OBD port is in an awkward place |
Beta Was this translation helpful? Give feedback.
-
This not necessarily true :). ALDI Australia offers a long expiry SIM, which I've been using, it's the cheapest plan I could find downunder. And there's plenty of of iot data SIMs out there comes down to couple of $ a month. |
Beta Was this translation helpful? Give feedback.
-
@philhawthorne all cars and trucks you can buy for the last 20-years in first world countries must have an ODB-II port by law (so does even most but the least expensive ”cars” from second and third world countries too), so unless you have a very old car or import a moped-car from Africa the chances are practically 100% that your car has an OBD-2 port. OBD-II becomame mandatory in the year 1996 for all cars manufactured in the United States. EOBD (European version of OBD-II) then became Since this OBD/EOBD standard aslo help car manufacters and most of those want to have the option to sell cars in the United States and/or the European Union they made a global practice of adding an OBD-II port to all car frameworks that are to be sold in all western countries. |
Beta Was this translation helpful? Give feedback.
-
Both the existing WiCAN and the upcoming WiCAN Pro use just Wi-Fi and Bluetooth as standard, but you will also have the option to buy an optional LTE (4G) addon-module in the future. All local only, no cloud, even if would use LTE. |
Beta Was this translation helpful? Give feedback.
-
There are flat OBD extension cords with low-profile connectors that you can buy. Search for keywords ”obd flat cable”. Examples:
|
Beta Was this translation helpful? Give feedback.
-
|
Very nice! Well when you're ready, we're happy to have someone on the podcast to talk about it, particularly for the Home Assistant integration and some very fun use cases. I do like the EV angle too. I assumed with things like Tesla having an app, they wouldn't expose an OBD port, so this might be an option for those that don't want to pay for Tesla fleet API access.
Just ordered one off Amazon to arrive on the weekend. Will give it a go - and if I can still close the fuse box I'll order one of these bad boys to test out |
Beta Was this translation helpful? Give feedback.
-
|
@Hedda Some users are connecting the WiCAN-USB directly to the harness using the screw terminal connector for power and CAN. https://sites.google.com/view/homeassistant-campervan/can-bus-integration |
Beta Was this translation helpful? Give feedback.
-
Yeah but for the new WiCAN Pro you would need to sell an optional OBD to screw-terminal converter adapter for that, or the users need to make their own by cutting a extension cord in half |
Beta Was this translation helpful? Give feedback.
-
I'm in the exact same situation, Can't even plug in the flat extension cable, I'm planning to 3d print a new cover for the fuse box with enough of a bump for the extension cable, for now I just live with the cover off, or jam wires in the connector so its slimline.
I'd be happy to chat on the podcast about it and the HA side of it, just messaged MeatPi and hes happy for me to do it as well, let me know how to get in contact with you and we can sort out details |
Beta Was this translation helpful? Give feedback.
-
|
Sure thing mate Just shoot us an email feedback at hasspodcast.io and I'll get it. Realistically you won't be on till sometime in 2025, but we can try work something out if timing is important for this project |
Beta Was this translation helpful? Give feedback.
-
Again, ODB-II port is required by law (for more than 20-years) in the USA and the EU, even on EV cars like those from Tesla. I would think that most other western countries have similar laws requiring a ODB-II port as standard for vehicle diagnostics at any repair-shop and official inspections for Automotive safley, like the MOT tests in the United Kingdom |
Beta Was this translation helpful? Give feedback.
-
|
@meatpiHQ can you as repo admin move this issue to discussions so do do not need to stay closed? https://github.com/meatpiHQ/wican-fw/discussions |
Beta Was this translation helpful? Give feedback.
-
Note! This is a follow-up to #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:
https://developers.home-assistant.io/docs/architecture_components/
https://developers.home-assistant.io/docs/creating_component_index/
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.
https://www.home-assistant.io/integrations/
https://www.hacs.xyz/
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:
Beta Was this translation helpful? Give feedback.
All reactions