Thanks for the insight. This whole HA thing can certainly be frustrating. My recent switch to Tasmota is kind of like switching everything to Wink right before they bricked everything unless you paid them a monthly ransom! The whole reason I got into Hubitat (in addition to its local nature) was I figured with the extensive community app developers, it would be relatively more open source and so less prone to these kinds of problems. Hopefully, the higher ups at Hubitat will consider incorporating a supported app for Tasmota as I’m sure there are a good number of Tasmota users in this same situation who have contributed grteatly to the success of HE.
Well it's my understanding that Tasmota isn't natively supported but supported through community drivers, so the question is not if HE will support it but will those writing the community drivers still support it.
2 Likes
Since MQTT is arguably a more “universal” interface language, would it make more sense for me to incorporate broker hardware and use MQTT to communicate between my Tasmota devices and Hubitat? To a novice, it seems to me that Hubitat is more likely to continue to support MQTT, and since Tasmota seems to continue to be developed and supported on its own, and also allows for MQTT, that this would be a way to keep my Tasmota devices working with Hubitat? Again, I am very new to all this and am not familiar at all with MQTT (just got a handle on Tasmota, lol). What does MQTT allow Hubitat to do (with a broker device such as a rpi) and can it do the same things that I am currently doing with the http hook in T4HE? Again, sorry for my lack of experience, but I am willing to learn.
MQTT will im sure continue to be supported by hubitat, the issue at hand though are delievering drivers for devices that support it. HE is "primarily" devoted to z-wave and zigbee. That said, it's up to the community to maintain the driver(s) for those devices as HE has bigger fish to fry. I would like to see them implement Thread support as well so the community can start writing drivers for that stuff. It would align with maintaining 100% local control.
1 Like
You could also take a look at using Node Red as your intermediary. I have a bunch of 433 MHz sensors that go through a Tasmatized Sonoff Bridge to then integrate with Hubitat virtual devices. I also have a few temperature/humidity/lux sensors that I built that do the same.
Node Red can integrate with a lot of different devices, hubs, etc. If you were to decide that HE didn't fit your needs, you could swap to another option with minimal changing in Node Red or your Tasmota devices.
2 Likes
Markus being banned was one of the reasons it took so long for me to update to 2.2.5. I was worried about something breaking, since the majority of my devices are Tasmota and Sengled. (Sengled was also having problems).
I've gotten pretty good at porting the HttpHook changes to new versions of the Tasmota firmware. I recently ported 9.3.1.1 if you check the thread here. I'll probably continue to do so as Tasmota adds cool new features.
The problem is Markus's beast of a driver. My understanding is it uses templates to detect specific devices. And Tasmota changed the template format in 9.1 I think, so if you have one of those devices it might stop working with later firmwares. I haven't really used Markus's drivers in awhile though because I've been interested in creating my own drivers.
I have some here:
Hubitat/Tasmota at master · Obi2000/Hubitat (github.com)
It's mostly generic switch, bulb, etc. drivers, and will never be as good as Markus's stuff. But at least on a simple level, as long as my Hubitat keeps working I plan to use Tasmota devices with it. So I'll probably keep these going.
4 Likes
This. With Maker API being a built in app, you can use all the zigbee and z-wave devices on HE (and Tasmota if on 8.5.1 webhook version) use Node Red to create lightning fast automations. I currently have 85 Tasmota 'things', mostly Lohas color bulbs, and Treatlife dimmers and switches. Currently they work on the now undeveloped T4HE version of Tasmota, but there will be no future revisions. This does not mean it is dead, it means moving more automations to NR.
It's up to you, for me, it comes down to cost. My color bulbs averaged $6.00 each, and the switches averaged about $9-10 each. Do that 85 times, and that is a very affordable way to go.
I plan on moving all of my automations to a Node Red, just getting started with that. It takes an effort, but it is so worth it in savings and automations with no HE delays. Good Luck
2 Likes
With Maker API, all of your Hubitat devices are visible within Node Red. You can then have NR automations that use Hubitat nodes, as well as MQTT nodes in the flows. There are other ways to do this, that is my current setup.
1 Like
Thanks to everyone for their great input. I should have mentioned that the things that brought me to Hubitat were 1) local control, 2) open source applications, and 3) and not necessarily in this order, the great community here. Being a complete neophyte, are there any specific recommended resources/articles/videos you can point me to to get me started/knowledgeable with 1) exactly how to set up an intermediary device (rpi etc), device specifications necessary (model, RAM, etc) to run MQTT broker and NodeRed? Also, 2) any specific vendors that are good to do business with to acquire the hardware? Any help would be great (as a newbie, I tried to learn all this by just searching the net but putting it all together was somewhat confusing). If you could point me to a step by step resource it would be greatly appreciated.
I genuinely believe at some point in the future a Tasmota version will exist that makes Hubitat integration much easier, let things play out, and in the meantime if it ain't broke, don't mess with it...
Tasmota works great for me and will happily keep it as long as possible, eventually Tasmota or Hubitat will change and it will drive a new and improved integration probably at that point.
I would like to add my support for Hubitat to support these devices having data controlled by China in the current environment would seem to be rather silly. When are they going to switch it off just to annoy everybody who does not do what they say. Tasmota resolves this issue nicely. It is incredibly good software for a non commercial product and Theo Arends is an really capable programmer, Hubitat should be leveraging on this and fully supporting the Tasmota protocol.
There is a third party hubitat integration for Tasmota that, in my experience, is rock solid. Support for it is hosted off of these forums though, for reasons, but just look at this github repo:
Colin,
While I appreciate your recommendation, I respectfully suggest that you may be missing the point of the topic. As the OP, the whole reason I brought up this topic is that I have been using T4HE (and agree that it is currently “rock solid” as a third party app can be) but because HE updates are no longer available to the T4HE developer (Markus), the last version (which will only work with Tasmota up to v8.5.1) is the final version and will no longer be updated.
Any further updates to the HE OS (for security reasons, new features etc) may eventually brick T4HE in the same way that old WindowsXP programs may no longer work with Windows10. You can certainly continue to use Windows XP to keep using these older programs (I am of course being facetious) and forgo the advantages of Windows10 or beyond, or lose the use of these programs. Likewise, because you cannot retroactively downgrade the HE OS, any future updates to the HE OS may “brick” the last version of T4HE.
In addition, you will be stuck - unless others can port the HTTPhook on T4HE v8.5.1 to later versions of Tasmota (currently v9.x.x and beyond) -using Tasmota 8.5.1 whereas some devices now currently require Tasmota 9.x.x for full functionality.
So although I understand your suggestion to use Markus’ app (and I currently do use it successfully . . . or am more accurately “stuck” using it) it does not really address the problem with potential future incompatibilities between HE and Tasmota due to further updates to HE. I think we can all agree that the willingness of the HE staff to update and continually improve and add features to HE is one of the strong points of Hubitat, but this may inadvertently adversely affect those of us that have invested in flashing Tasmota in order to keep our IOT devices from calling home, and keeping things local was one of the selling points of HE to begin with.
That is why the answer would ideally be Hubitat bidirectional official integration for Tasmota in the way Hubitat provides official integration with other third party devices (albeit hardware devices and not necessarily third party software such as Tasmota).
Hope this makes sense (sorry for the long rant).
1 Like
All valid thoughts of course.
But I'll suggest that the lack of posts in this thread by Hubitat is likely an indicator of their interest in this (at least at this time).
Good to ask for what you want though. Never know what will happen in the future.
4 Likes
Anyone this far into it HA to be able to do Tasmota has the skill sets to do Node Red 
It is worth investigating moving automations over to Node Red. They are extremely fast, and can still integrate with HE fine.
For me, I've got 79 Tasmota devices, and many automations in Node Red. I tie the Hubitat nodes into NR for the motion and open/close sensors, and the switches and bulbs via MQTT.
With the writing on the wall for the future of Tasmota for HE, this is worth looking into.
4 Likes
@moh, I have written a set of Hubitat drivers for Tasmota 11 that perform realtime and native synchronization between the two platforms without any need for an HTTP hook or special compilation of Tasmota. See here for more info [RELEASE] Tasmota Sync - Native and Real-time Synchronization between Hubitat and Tasmota 11 or later
[quote="moh, post:16, topic:69885"]
it does not really address the problem with potential future incompatibilities between HE and Tasmota due to further updates to HE.
[/quote] The parse() method used by Tasmota drivers is the same method that is used by all Zigbee and ZWave devices. Tasmota integration uses the "front door" so to speak.
6 Likes
Hi @garyjmilne,
Since my original post just over a year ago, I have become aware of your fantastic Tasmota 11 drivers and have been converting my devices from Markus’ old drivers since your release. Thanks for updating this thread so that others will also be aware of your work! Great stuff. Thanks for all your work in addressing this issue. It is greatly appreciated.
3 Likes
@moh Sorry, I had not recognized your name. I was looking for something else when I came across your post.
2 Likes
No problem at all! The more Tasmota-philes that become aware of your drivers the better. Your work has really addressed the major concerns many of us have had since Markus’ departure and the fact that your driver can handle the integration without HTTP hooks using native Tasmota is killer. Thanks again!
1 Like
