I am experiencing exactly the same issues
And that only applies if you use the “attribute:” option and doesn’t change anything if that option isn’t used?
For example:
when using a normal state trigger (without the attribute) you could put the state in without converting it to a string. The only thing that you needed to explicitly define as a string was “off” & “on” to avoid confusing them with booleans.
I’m pretty sure that this worked:
trigger:
platform: state
entity_id: device_tracker.me
to: home
Does it still?
That change seems to be saying that if I use the simple state trigger that I can still put the “to:” values in without explicitly converting them to strings but if I use the “attribute:” I now have to explicitly convert the compared value to the correct data type for it to work?
So I assume this wouldn’t work (contrived example):
trigger:
platform: state
entity_id: device_tracker.me
attribute: source_type
to: router
since the “to:” value (router) isn’t explicitly defined as a string?
Same here. All my OVNIF cameras are gone in 116.3.
And the “not a Frame instance” (google cloud tts) problem is still there too.
It’s free, so not complaining, but next time I’ll wait even longer before upgrading…
I revereted to 116.2 and it’s all working again. I’m sure it will be fixed quickly.
Me too, just upgraded to 0.116.3 and:
[homeassistant.setup] Setup failed for onvif: Unable to import component: No module named 'zeep.asyncio'
and as another point of information…
I just saw that this exact scenario was the point of confusion in another thread.
In that thread the OP was using an attribute that contained the boolean false but used a string 'false' for the comparison value in the condition. Which caused the condition to not be satisfied.
I guess I’m not sure how to know for sure what the data type would be in the attributes for the case where there is an equivalent string value for some other data type.
For example how does one know to use false or "false"? or 3 or "3"? Is it now just trial and error as it was in that other thread or is there some obvious (except to me) way of knowing what the correct data type is that needs to be used?
And again is this only used for the attribute comparison or also the state comparison?
1 Like
Same here. All my OVNIF cameras are gone in 116.3. 
Correct. States are always strings and home assistant treats the state trigger options as if they contain strings.
Not sure. Without the quotes are a bunch of letters assumed to be a string?
I’d err on the side of caution and include the quotes.
Here also, am just glad its not just me… 
Same error for mi for Onvif in HA 116.3
Lots of people reporting onvif errors, but no one saying they have posted a github issue. sigh
5 Likes
And then if it’s not a string the condition will fail without you really knowing why without a lot of faffing around as in that example thread above. TBH, I never would have guessed that including quotes around “false” would have caused the condition to fail since we have been told to do it that way since forever. I would have suggested submitting it as a bug in the template evaluator.
And how would we define other data types? the only one that comes to mind is a datetime object. How do you define that? Or would that be just treated as a string (failing the new “you have to code the data as the correct data type” requirement)?
It seems that this change just added unnecessary confusion when everything before “just worked”. I guess apparently there were times that in treating everything as strings “made it work for some values, but not all” but I’ve been using HA for 3 years and never ran into a situation that I couldn’t get it to work the way that it was. Maybe I was just lucky…
Also, @tom_l, I’m not expecting you to provide these answers. It would be nice if a dev would pop in and provide specifics.
1 Like
It’s going to get more confusing (and powerful) with templates:
To add to that: in my case, I’d used the web GUI to create that condition which created created it as a string. Had I edited the file directly I’d probably have just assumed that true / false was an actual boolean and not a string, but I didn’t think to go double check what the frontend had written to the automation file. If folks are purely using the web frontend, I could see this being an issue.
I’m stuck with Onvif in integrativo too
Fair enough. 
I jumped in to report an issue after reading your comment and it looks like it was reported well before I posted the first ONVIF comment. Looks like progress is being made already. 
Why yes it is…
I think the option to revert to “legacy mode” won’t really be much of a help unless you can piecemeal your existing templates to the new rendering scheme.
If it’s going to be all or nothing then we’ll basically need to have two entirely different equivalent configs in order to test each template in the new scheme to see which ones need “special attention” in order to get them to work as expected while still allowing us to maintain our systems running.
I can’t imagine it’s going to be trivial to switch all the templates that I currently use to the new way. Just doing a quick text search for “template:” in my config files pulls up 918 hits. Granted not all will have to be changed but wading thru every one of them to see if they do is going to be pretty daunting.
EDIT:
Not to mention the thousands of posts on these forums and elsewhere that say “templates always return strings”. Talk about confusing things…
same for me
Logger: homeassistant.setup
Source: setup.py:138
First occurred: 20:48:27 (1 occurrences)
Last logged: 20:48:27Setup failed for onvif: Unable to import component: No module named ‘zeep.asyncio’
Been hands on since '17. One upgrade i managed somehow by just throwing random commands from various guides. The 2nd time around I ended up upgrading the OS and ran a few commands after and got it going. The 3rd everything failed and ended up building a new OS from scratch (pain in the ass even after you move config files). The fourth time now… Guides are way more detailed and I think I’m close but damn is it hard for someone that doesn’t use python in their daily vocabulary. I see this as being a huge turn off attracting new users to hass. You could go the docker route but that requires a whole other learning curve and understanding. You could go the hass.io route but that requires $$$ and a whole bunch of your data sitting on the cloud. Just my .02 Followed the newer guide and all hell broke lose. Giving it another go using the new includes. And yes, your family does stone you to death when hass is down lol
Yep good to see. I see there is a workaround for now too.
pip install python-zeep
2 Likes