That is what i thought you meant. But once you get it working you should be able to integrate it. One more thing worth mentioning is that the new driver will handle multiple sensors on the same Tasmota device.
Uuuuh, this is nice. Multisensor, I'm comming. 
For those following this thread I have updated all of the Switch\Plug drivers. They are now all based on common code with just two lines modified to create each version for Single\Dual\Triple\Quad\Eight port versions.
I misunderstood how HPM worked (never published with it before) and long story short you may have to select the new device driver for the device once it is installed. The new ones are all of the form Tasmota Sync - XXX_Relay/Switch/Plug where XXX describes the number of relays in the device.
If you do have to switch to the new device driver be sure and click on Save Preferences to bring the device up to date with the latest settings.
1 Like
@garyjmilne We seem to have lost the "Toggle" command in the new common code.
I know how to fix my local copy, but figured I needed to let you know so you can fix your master copy on github.
Thanks for pointing that out Mark. I will update and publish tomorrow.
1 Like
Just curious... When I was running Marcus drivers on my power monitoring plugs, there were several other power/energy attributes available. Have you considered adding them or is there a particular reason you left them out?
This has been restored in version 1.2.3 now on HPM.
I did leave them out for a reason, each attribute change results in a log entry and I felt that having 9 attributes change on a device every 10 - 60 seconds or so made the history difficult to digest as there is no filtering. That is why I introduced the "relayType" option in settings so people could dial in their own level of detail.
You are not the first to enquire about the availability of the other Tasmota Energy fields so I have added another relayType for ALL Tasmota Energy stats.
To access this you must upgrade the drivers to V1.2.3 which you can do with HPM. Then change the relayType to that shown above.
Finally, don't forget to injectTasmotaRule to tell the Tasmota device you are now interested in gathering different information.
Once you do that you will start to get all the Tasmota Energy info and it will look like this.
Check your logs and you should see the sync requests coming in at whatever you have set the Teleperiod to. In this case it was 15 seconds.
But remember the downside is a log of event entries for the device, one per each attribute change.
relayType - All Switch and Tasmota Energy Stats
relayType - Only Switch and Power Events
Like I said, now you can dial in the level of detail that you want.
1 Like
Thanks a million for making these update 
. But I’m confused. Are you saying that we only get these new attributes the old way via teleperiod polling intervals? I thought one of the aspects of your new driver and tasmota 11 was it pushes the data when it changes and doesn’t need the frequent polling
Certain changes on Tasmota are reported back immediately such as switch, dimmer, color, CT, FanSpeed, fade etc. Sensor data, which includes energy, only get's transmitted at the TelePeriod. The lowest teleperiod is 10 seconds.
It is possible to trigger on sensor data but sensor updates happen once per second in the documentation that I have read. That means your Hubitat hub could be getting hit 60 times per minute for each device that you had. That would be really bad for the Hub performance and you would not like the result.
You have to ask yourself how responsive do I want something to be in order to fire HE rules. That will dictate your Teleperiod. Even though it can go down to 10 seconds mine the minimum I use is 60.
1 Like
I totally understand that. It's the way it was with Marcus's drivers. I also use minimum 60 and in many cases higher than that. It's just that I thought Tasmota 11 and your new drivers were able to make the sensor data pushable (not requiring Teleperiod polling). I guess I misunderstood.
I still like getting rid of the child devices though. That always bugged me 
Tasmota still pushes the sensor data using my drivers. More accurately the Rules\Triggers that are injected into the Tasmota device cause it to send unsolicited data to HE. What you see in the logs is the reception of that unsolicited data by HE.
These unsolicited inputs are routed to the syncTasmota function, meaning these exchanges are initiated by the Tasmota device. So sensor data is pushed. It occurs at the Teleperiod because if it were live it would overwhelm the Hub.
The only time HE pulls data using my drivers is if you A) manually click on Refresh.
These show a request being made by HE (callTasmota) and the response coming back (routed to hubitatResponse).
or B) if you setup the Polling method as you referenced above. A polling entry identifies it as such and then it calls the Refresh function.
I have two devices that did not tolerate Tasmota 11 well which is why I have them polling occasionally.
I hope that explains things more clearly.
2 Likes
Me too, my ratio of parent to child devices was very close to 1:1 so it felt like overkill. Now it is just more pleasing to look at and I like not being several years back on Tasmota or dependent on a particular Tasmota compilation.
3 Likes
I understand that enabling all the attributes creates excessive (and often unuseful) event entries
yeah, I think I may edit my local copy to pick and choose the attributes. I wanted more than just switch and power values. I don't really need voltage, but Energy is commonly used so I wanted to add those.
Best way to do that might be to grab a copy of the rule and edit it down to just the fields you want. Makes you less susceptible to code changes. I believe the code should handle that as is.
1 Like
Just a short question. The current driver will be able to handle multiple sensors, right? In the panel "Tasmota Sensor Same", how do I have to type in the name, using multiple sensors? I'll give the combined Ikea PM2.5 and BME280 a chance.
The currently published sensor driver one only handles a single sensor. The new one isn't quite finished but you can try an early version here if you would like. It's not part of HPM yet so you would have to install it the old fashioned way.
After you install it and configure the Tasmota IP and Hub IP do a "Refresh" command to make sure communication works and discover the sensors.
Then do a refresh of your browser to update the state variables. You should see something like this.
Hopefully your sensors will be listed. If they are then you are all set and you can now do a tasmotaInjectRule, set your TelePeriod and the updates should start coming in.
If your sensors don't show properly on Hubitat but they do show on Tasmota then do a "status 8" on the Tasmota console and send me the result.
I'm using JSON data to simulate sensors vs actual real live sensors in most cases so this is still beta. I should get a bunch of sensors tomorrow to do some more rigorous testing. I have a few things to figure out on how Tasmota handles multiple switch devices such a prox sensors or touch sensors and the naming of those switches. Let me know how it goes.
This sounds relatively straight forward. I've installed it and give it a shot this weekend.
Hi @garyjmilne, by the way AWESOME news. I am changing mine today at least for the wall 2/3 gangs swtices!!!!
My request goes for the IR blasters and SONOFF RF 433 bridge. Are you planing to do something for those? Thanks a lot!
I bought a Sonoff RF bridge but they have revved the board to V2.2 and changed the RF chip so its no longer compatible with Portisch.
I would to adapt a driver for it but need to get an older version. Won't happen anytime soon though as i'm going to be gone for 4 weeks.
Got some light strip controller's so that is probably my next driver when i get back although it should not take too long.
1 Like
