After upgrading to 0.116.1 and 0.116.2. I Get the same thing.
Drop down from the order package: 183510 <= 183510
The log is filled with this…
Same issue after upgrading to 116.2
2020-10-10 03:45:51 WARNING (stream_worker) [homeassistant.components.stream.worker] Dropping out of order packet: 133290 <= 133290
2020-10-10 03:45:51 WARNING (stream_worker) [homeassistant.components.stream.worker] Dropping out of order packet: 133020 <= 133020
2020-10-10 03:45:52 WARNING (stream_worker) [homeassistant.components.stream.worker] Dropping out of order packet: 137430 <= 137430
2020-10-10 03:45:52 WARNING (stream_worker) [homeassistant.components.stream.worker] Dropping out of order packet: 137430 <= 137430
I just spent half a day trying - without success - to upgrade my venv on a RPi 3 from Python 3.7 to 3.8. I had to eventually give up since there are too many packages (e.g. lxml) for which there are no Python 3.8 wheels on piwheels and which just take forever to compile (and eventually fail). And I did successfully convert from 3.6 to 3.7 when 3.6 was deprecated a while back, so I think I know what I’m doing.
I find this rush to deprecate Python versions really frustrating. Yes, I understand it reduces maintenance workload and CI minutes. But the additional features brought especially by Python 3.6 that justified introducing the new policy in 2018 are not an argument anymore when deprecating 3.7. Which feature in 3.8 do we need in HA that is not present in 3.7?
To me this is another example of how “alternative” installation methods (i.e. everything which is not what used to be called Hassio) are being pushed out more and more. I’m guessing I’m not the only user who is still running their home on what used to be the recommended installation method (venv) and who is afraid that a migration to supervisor will break everything and cause a family mutiny.
Don’t get me wrong, I’m incredibly grateful to all the fantastic work all contributors are doing 
and I also hate having to maintain compatibility with years old versions of Python. But on the other hand, is this strict adherence to the “two-version policy” really necessary in a time when new features are much more sparse?
It would be really great if you could reconsider the decision and keep my house running on 3.7 for a little while longer. 
4 Likes
Same here. Same problem as with .115 by the looks of it. This time I waited until the .2 version.
Oh well… maybe in 116.3
That is what made me move from venv a while ago, Not that I know enough about the python deprecation policy to venture an opinion, but the docker approach does it all for you.
You do have two months to upgrade python though. 3.7 is deprecated, not unsupported.
Starting a brand new venv is the way to go though, from what I have read. Just move your config.
2 Likes
Bookmark this post and just follow the steps when you need to do it.
2 Likes
Thanks @dshokouhi! I didn’t know this post, but actually that’s the exact procedure I followed. The reason it did not work was the pip install -r requirements.txt, since some of my integrations required packages (for instance lxml) that do not have Python 3.8 wheels on PiWheels, only 3.7. This is becasue PiWheels mostly focuses (see e.g. here) on delivering wheels for the latest Python versio supported by Debian stable, which is 3.7. This is why moving to 3.8 will cause many people trouble, in my opinion.
Updated to 116.2 from 115.3: Under Configuration:Integrations, two of fourteen squares for the integrations are missing the bottom line “RENAME :” They are the Denon and Mobile App integrations.
Did restart and flush cache on browser (Chrome on PC). Same problem with Android Mobile App with the same two integrations.
Applied 0.116.2 update this morning, lost my AlarmDecoder alarm control panel entity. Tried many things, finally reverted to 0.115.6. Alarm control panel entity returned, as did display on home page. Any one else seeing similar behavior? Repored as Issue # 41664 at GitHub.
Closed the issue as an RTFM problem with the operator. PEBKAC. ID10T. 
Same issue here. Any solutions so far?
I’m seeing this type of error pretty regularly:
Logger: homeassistant.components.stream.worker
Source: components/stream/worker.py:240
Integration: Stream (documentation, issues)
First occurred: 23:33:46 (1 occurrences)
Last logged: 23:33:46Timestamp overflow detected: dts = 190446, resetting stream
1 Like
Are broadlink switches broken?
after upgrade to 0.115 did everything in breaking chages, but switches never worked. 0.116 the same.
- platform: broadlink
mac: 34:EA:34:XX:XX:XX
switches:
- name: Philips TV
command_on: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
command_off: JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=
Switches just dont show up. Integration is set up.
I think you’re missing the b64: bit (to indicate it’s base64 encoded data) in your commands, e.g.:
command_on: b64:JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
nop 
, it is 1:1 as in documentation, and with b64: config does not validate
Invalid config for [switch.broadlink]: not a valid value for dictionary value @ data['switches'][0]['command_off']. Got 'b64:JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA='
problem is that there is nothing in logs, but switch.philips_tv is not created.
I think that it would be wise to wait with depreciating a python version until there is a package (.dep) version available of the new python version on Raspberry Pi OS (the former Raspbian). Today there is no default package available for python 3.8 but already python 3.7 is getting depreciated. Having to compile the core part of the system is, in my eyes, too much too soon.
Broadlink switches are deprecated. You should now be implementing them as scripts. here’s an example from my config that works.
EDIT - this was incorrect - please see the post below
soundbar_toggle:
alias: Soundbar Toggle
sequence:
- service: remote.send_command
data:
command: b64:JgBYAAABJZUQFRE4ETkRFBEUERQRFBE5ETgRORE4ETkROBE5ETkQOREUERUQORE4ETkRFBEUERUQORE4ERQRFRAVETgRORE4EQAEuQABJksRAAxeAAEmShEADQUAAAAAAAAAAAAAAAAAAA==
entity_id: remote.broadlink_rm4_mini_remote
mode: single
icon: mdi:speaker
I believe there are also issues with some broadlink devices that aren’t currently working. - i’ll try and find the thread and add.
Thanks, did not saw anywhere info that Broadlink switches are deprecated. Got the same functionality with template switch. 
- platform: template
switches:
philips_tv:
friendly_name: Philips TV
value_template: "{{ is_state('device_tracker.philips_tv_wifi', 'home') }}"
turn_on:
service: remote.send_command
data:
command: b64:JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
entity_id: remote.broadlinkpro_remote
turn_off:
service: remote.send_command
data:
command: b64:JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=
entity_id: remote.broadlinkpro_remote
Can it be, that netatmo is broken again?
Already restartet, no integration. 116.2
GitHub issue is open: https://github.com/home-assistant/core/issues/41718
1 Like
Hi All,
Im experiencing trouble with linking my Netatmo account with home assistant.
When I go to the integrations page and add Netatmo, im redirected to the site of Netatmo where I need to give permission to share device information.
When I click accept, Im taken back to a Nuba casa page where the system is waiting for a token, however it always times out and fails the linking procedure.
I have tried the same with Google assistant and it linked just fine.
But if I look in my Netatmo account page for third-party applications its shows the Home Assistant Cloud and Google Assistant.
Has anybody have an idea why it is not working, and how to get it to work.
I have already tried with version 116.0 but I got the same result as 116.2
@Pirol62 @Jordy_Kleian It seems to be a back end issue at Netatmo. Nothing we can do about.
Edit: I’d recommend reverting back to individual dev accounts until this is solved.