Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad behavior of Fully Kiosk Browser with the new 2023.12.0 HA core #105263

Closed
pickonedev opened this issue Dec 7, 2023 · 33 comments · Fixed by #105735
Closed

Bad behavior of Fully Kiosk Browser with the new 2023.12.0 HA core #105263

pickonedev opened this issue Dec 7, 2023 · 33 comments · Fixed by #105735

Comments

@pickonedev
Copy link

pickonedev commented Dec 7, 2023

The problem

The problem is that after the update to 2023.12.0 HA, when I try to use the Fully Kiosk Browser integration, it is acting very strange. If I press the screen switch, the screen saver will go on as well, if I press the motion switch, it will switch both (screen and screen saver) on, but this time, the screen of the tablet, remains off...
And one more thing, but it's all in the video, the switches are flickering to on/off when I use them... it is very strange

Vid.20231206.232604-1.mp4

What version of Home Assistant Core has the issue?

2023.12.0

What was the last working version of Home Assistant Core?

2023.11.X

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Fully Kiosk Browser

Link to integration documentation on our website

https://www.home-assistant.io/integrations/fully_kiosk

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

@home-assistant
Copy link

home-assistant bot commented Dec 7, 2023

Hey there @cgarwood, mind taking a look at this issue as it has been labeled with an integration (fully_kiosk) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of fully_kiosk can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign fully_kiosk Removes the current integration label and assignees on the issue, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


fully_kiosk documentation
fully_kiosk source
(message by IssueLinks)

@cgarwood
Copy link
Member

cgarwood commented Dec 7, 2023

cc @mheath - could this be related to #89010 ?

@pickonedev do you have MQTT set up in the Fully app?

@pickonedev
Copy link
Author

pickonedev commented Dec 8, 2023

Yes, I do. I use MQTT on all my tablets which uses Fully App. This is the only way I use them.

Edit: The screensaver swtich will toggle (on/off) even if I turn on the screen from the web fully kiosk, not only from the integration...

Edit2: It is even more strange when I tried to see if the integration get the same values/actions as from the web access of the app (about the screen and screensaver switches, you will see again that it is acting strange as before)

2023-12-08.14-47-50-1.mp4

@pickonedev
Copy link
Author

pickonedev commented Dec 9, 2023

@cgarwood , @mheath if this can't be repaired or it is not a general issue, it s ok, just tell me to not wait in vain. I can create my own needed sensors and switches, in order to properly work.

Edit: or there is any possibility to go back and install the old version of this integration?

@RoxyPoxy2015
Copy link

I just noticed that I have the same issue....
I didn't know why some of my tablets are not turning on the screen, because in the back of the integration, the screen was "on", but the screen of the tablet "off", and I have a PIR rule which turn on the screen of the tablet only when it is off.
And when I turn on the screen from the integration, I see the same problem as from the videos of @pickonedev

@TrutaIonM
Copy link

same here

@MMDaemonD
Copy link

+1 same

@cgarwood
Copy link
Member

What version of Fully are you running? I've tried with one of my tablets and so far haven't been able to reproduce the issue 🙁

@pickonedev
Copy link
Author

pickonedev commented Dec 13, 2023

I am using 1.54.1-emm, this is what the developer has recommended me to use, in order to use the "deployment" feature, with no issues.

@cgarwood There is any way to change the Fully Kiosk Integration to a past version? In this way, I can check which version is cousing the problem, by installing older and older versions

@MMDaemonD
Copy link

com.fullykiosk.emm 1.54.1

@cgarwood
Copy link
Member

There is any way to change the Fully Kiosk Integration to a past version? In this way, I can check which version is cousing the problem, by installing older and older versions'

https://github.com/home-assistant/core/commits/dev/homeassistant/components/fully_kiosk has the commit history for the component. Everything up to commit 3bbed89 was included in 2023.12

Otherwise the last real update to the integration itself was in June (commit 3482757) which would have shipped in 2023.7.

You can download a copy of the fully_kiosk folder from any commit, add a version key to the manifest.json file and stick it in your custom_components directory to use an old version. This would also allow you to add additional logging statements if you're up for it

I tried on a couple more tablets today and so far haven't been able to reproduce on any of mine, so this may end up being a fun one to troubleshoot

@pickonedev
Copy link
Author

pickonedev commented Dec 13, 2023

Wait, tablet?! No, I was doing this from pc (firefox browser), I will check on my phone with Companion app as well.

Edit1: Save result from phone as well, same from tablet, the switches are going crazy :))

WhatsApp.Video.2023-12-13.at.23.08.57_6785ac05.mp4

@pickonedev
Copy link
Author

pickonedev commented Dec 13, 2023

@cgarwood , till I will test with older version, I will give you a video which contains the real video with the tablet and the screencapture with the HA (touches on this time), in order to see how the tablet it is acting, depending of what I press... It is messed up good...
Of course, it is not about the tablet, it is about the switches from the integration, I think. I tested with three different tablets, with phone (fully browser installed), same result...

a.mp4

@pickonedev
Copy link
Author

I added the version from 6 months ago, everything is good...
@cgarwood If you want me to test anything else, in order to help everyone with the integration, please tell me.
In this moment, with the old integration, the switches are ok, no crazyness 🥇

@MMDaemonD
Copy link

I'm a noob, but if you can explain me better how to put the old version as well, it would be great

@pickonedev
Copy link
Author

pickonedev commented Dec 13, 2023

4e3ff45 this one it is working good
d460ead this is not acting good....
aa4382e same, strange...

Seems that from this commit "d460ead", it is the issue...

Sometimes when the functionality it is not good, with a specific feature from HA, I reboot the device, but this time, this does not solve this issue... :-(

@MMDaemonD no need to try, I will lose some time with these checkings. But still, if you really want, just download the files of the commit, create folder "fully_kiosk" to the custom_components folder, then add a version to the manifest file, take example from other files.

@cgarwood
Copy link
Member

Wait, tablet?! No, I was doing this from pc (firefox browser), I will check on my phone with Companion app as well.

By tablet I meant controlling Fully running on a couple different tablets. I was using Chrome on my desktop to actually flip the switches in HA.

@pickonedev
Copy link
Author

pickonedev commented Dec 14, 2023

Same issue using Chrome as well... :-|

I think the issue it is from the integration, not from the brower we use. I talked with the developer of the Fully Kiosk Browser and he said that there is no issue with the browser. I tested different versions of the browser, same issue.

Edit1: I have even loaded HA in safe mode, without any custom addons, the problem persists... More and more evidence that the issue it is from the integration.

Edit2: Running browser from incognito, the issue still presists (in case of thinking about cache problems)

Edit3: Looking at the problematic commit, the one with "Add support to fully_kiosk for hybrid local push/pull switches using...", as far as I understand the changes, if I understand correctly, the update somehow listen for MQTT and it will update the switches state, regarding the MQTT received, but somehow it is doing wrong... If it helps, I was already doing this before this update came out, I already had my switches updated in real time, with the help of an automation and a py script which only set the state of entities, but not taking action as well... Here is the automation, if it helps somehow:

alias: Tablets - MQTT Screen2State
description: ""
trigger:
  - platform: mqtt
    topic: entrance_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: entrance
  - platform: mqtt
    topic: kitchen_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: kitchen
  - platform: mqtt
    topic: living_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: living
  - platform: mqtt
    topic: computer_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: computer
  - platform: mqtt
    topic: gym_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: gym
  - platform: mqtt
    topic: dressing_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: dressing
  - platform: mqtt
    topic: bedroom_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: bedroom
  - platform: mqtt
    topic: home_tablet/event
    payload: trigger_template
    value_template: >
      {% if value_json['event'] == 'screenOn' or value_json['event']  ==
      'screenOff' %}trigger_template{% endif %}
    id: home
condition: []
action:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{trigger.payload_json['event'] == 'screenOn' }}"
        sequence:
          - service: python_script.set_state
            data_template:
              entity_id: switch.{{ trigger.id }}_tablet_screen
              state: "on"
      - conditions:
          - condition: template
            value_template: "{{trigger.payload_json['event'] == 'screenOff' }}"
        sequence:
          - service: python_script.set_state
            data_template:
              entity_id: switch.{{ trigger.id }}_tablet_screen
              state: "off"
mode: parallel
max: 8

Edit4: The automation was disabled when I tested for issues of the problematic commit, to be sure that I don't create the problem

Edit5: I don't know if matters, but I use my tablets with a different topics, as can be seen in the automation above, I don't use standard topics, I changed the default settings

image

Edit6: Because I tested more commits and all were good till I tested this one "d460ead", it is 100% that the issue starts from this commit... Somehow, it is not doing what it should, or at least, not for some of us, that is for sure...

Edit7: Oh, by the way, because of this issue, sometimes I see the screen switches on, for some tablets, even if those tablets have the screen off in reality...

@MMDaemonD
Copy link

@pickonedev about your "edit5", I use non-default data as well, but this should not be the problem, I guess... If the person which created the feature of that commit, should think about using non-default details, right? I don't think this is the issue

image

I tested with ingognito as well, thinking about cache, but nope.

@pickonedev
Copy link
Author

Could @mheath check the changes of the problematic commit, keeping in mind the informations from us? Maybe somehow it will solve the issue...

@TrutaIonM
Copy link

There is any way to change the Fully Kiosk Integration to a past version? In this way, I can check which version is cousing the problem, by installing older and older versions'

https://github.com/home-assistant/core/commits/dev/homeassistant/components/fully_kiosk has the commit history for the component. Everything up to commit 3bbed89 was included in 2023.12

Otherwise the last real update to the integration itself was in June (commit 3482757) which would have shipped in 2023.7.

You can download a copy of the fully_kiosk folder from any commit, add a version key to the manifest.json file and stick it in your custom_components directory to use an old version. This would also allow you to add additional logging statements if you're up for it

I tried on a couple more tablets today and so far haven't been able to reproduce on any of mine, so this may end up being a fun one to troubleshoot

I done this, I am using the integration commit from 6 months ago, everything it is working good.
I will keep this version till the new one will be repaired. Thank you!

@cgarwood
Copy link
Member

I believe the custom MQTT event topic you're using is the issue, as it's missing the $event variable. This means every event gets published to the same topic, so in the MQTT broker a screenOn event, screensaverOn event, onMotion event, etc all just show up as a payload to computer_tablet/event topic instead of computer_tablet/event/screenOn computer_tablet/event/screensaverOn etc.

Try changing your MQTT Event topic to:
computer_tablet/event/$event for @pickonedev or tt_general/events/$event for @MMDaemonD

@pickonedev
Copy link
Author

pickonedev commented Dec 14, 2023

That is the "problem" for sure, this is why I told you about the custom MQTT settings. I was looking to the code of the "problematic" commit and I saw that it is using the $event variable, which I don't use, seems that MM it is doing the same.
The workaround (not solution, it's an workaround), it is like you said, to write the $event at the end of the topic, but still, as a solution, can't the integration get what the user have configured in the browser and use it like so?

Maybe someone wants to have the settings like me, not case for me because I will change the settings right now, but maybe someone doesn't want this...

Edit1: To me it is ok with the change of settings, because I won't use the old automation I made... so... it's fine.

Edit2: I made the test and I can confirm what we already figured out, with the variable in the topic name, the issue has gone. Thank you for your help @cgarwood

Edit3: Now the issue with the switches acting like crazy, has gone, but there is another issue :-D As far as I understood, that "problematic" commit, should update the switches state imediately, if I turn on the tablet, the switch should act fast, but for me it doesn't do nothing... If I turn on the tablet from the power button, the switch screen from the integration, stay off... Should I change something else or I should modify my old automation and use it?

@TrutaIonM
Copy link

That is the "problem" for sure, this is why I told you about the custom MQTT settings. I was looking to the code of the "problematic" commit and I saw that it is using the $event variable, which I don't use, seems that MM it is doing the same. The workaround (not solution, it's an workaround), it is like you said, to write the $event at the end of the topic, but still, as a solution, can't the integration get what the user have configured in the browser and use it like so?

Maybe someone wants to have the settings like me, not case for me because I will change the settings right now, but maybe someone doesn't want this...

+1 (can't this be a feature functionality request ?)

@MMDaemonD
Copy link

I am changing the settings too, but yes, I agree with @pickonedev, could this be added to the new version/commit?

@PanaitAART
Copy link

I have the same issue, I was wathing this post for few days and yes, it would be great if the integration will get the data from the configuration of the browser without that variable, because I can't change nothing to my tablets, I have some guys which do the maintenance and everything I change in my smart home devices, will take too much time, they are not available everytime...

@cgarwood
Copy link
Member

PR submitted that should fix the issue: #105735

If you would like to test, you can pull the fully_kiosk folder from here and add it as a custom_component:
https://github.com/cgarwood/home-assistant/tree/c2ab9b5c8c31540a507cd548918d12a5a3f5f15c/homeassistant/components/fully_kiosk

@pickonedev
Copy link
Author

pickonedev commented Dec 14, 2023

I will test it right now :-)

But still, there is a problem with not updating the switches if I turn on the tablets from the power button...

Edit1: I have test it, no switches crazyness, but it is only updating the switches if you use "/$event" in the event's topic. With custom it won't update, but the switches are not crazy :)))

Edit2: I can reconfirm this, if you use "/$event" into the event's topic, everything works perfectly, switches updates instantly, all good. If you don't use "/$event" and you use like me in the past, the switches of the integration are not updating, but there is no switches crazyness

Edit3: @cgarwood if you need more tests, i'm here for the next 4 hours.

Edit4: When the new version can be officially updated?

@cgarwood
Copy link
Member

Are you restarting HA or reloading the integration when you change the event topic? The MQTT subscriptions only happen when the integration is loaded.

@pickonedev
Copy link
Author

pickonedev commented Dec 14, 2023

I am restarting HA everytime I make changes to files or other yaml. I never used reloading.

Edit:

  • With this home_tablet/event/$event all good, switches from the intregration updates instantly and no funny switches
  • With this home_tablet/event, integration switches not updating, but no funny switches as well

Edit2: Wait, it is working. I needed to reboot the machine. Somehow something was stuck there... Now it is working good.

Edit3: For me, I think it is even better if I use $event, because I like how the information it is sent. For others, it could help to use it with custom topics.

When the new update will be available?

@cgarwood
Copy link
Member

PR is marked for 2023.12.3 hotfix, assuming it gets merged in time.

@pickonedev
Copy link
Author

Niceee! If I can do something else to help, please, don't hesitate to tell me.

@MMDaemonD
Copy link

Thank you @cgarwood and @pickonedev for the time.
I have changed the topics as well, for the same reasons, to have a better info

@github-actions github-actions bot locked and limited conversation to collaborators Jan 13, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants