TV automatically turning on early morning

[Flashback1]

This seems to be happening fairly regularly now (and has for some time), I’ve only noticed it again as I’m up early and doing something else and then heard my TV + AVR fire up after.

It seems to occur around 3.59am each day - is there a way I can see what’s causing the Vero V to wake up and therefore turn on my TV, Amp etc.?

Is the only way to get more insight to turn on log debugging and then wait till the next day to see what shows in the logs, or is there something in the standard logs I might be able to review?

[grahamh]

I was getting this because I back up my Vero every night. When Kodi was restarted, the TV was turning on by CEC. Fixed it by disabling CEC on the TV (which I don’t use). If you turn on CEC debugging you may find something interesting.

[Flashback1]

I had a quick search but wasn’t able to work out how to turn on CEC debugging, sorry.

I did run cec-client though, I’m not sure if that’s of any help?

x@osmc:~$ cec-client
No device type given. Using 'recording device'
CEC Parser created - libCEC version 6.0.2
no serial port given. trying autodetect:
 path:     /dev/aocec
 com port: AOCEC

opening a connection to the CEC adapter...
DEBUG:   [              65]     Broadcast (F): osd name set to 'Broadcast'
NOTICE:  [              65]     connection opened
DEBUG:   [              66]     processor thread started
DEBUG:   [              66]     << Broadcast (F) -> TV (0): POLL
TRAFFIC: [              66]     << f0
DEBUG:   [              95]     >> POLL sent
DEBUG:   [              95]     TV (0): device status changed into 'present'
DEBUG:   [              95]     << requesting vendor ID of 'TV' (0)
TRAFFIC: [              95]     << f0:8c
DEBUG:   [            1159]     expected response not received (87: device vendor id)
TRAFFIC: [            1160]     << f0:8c
DEBUG:   [            2213]     expected response not received (87: device vendor id)
DEBUG:   [            2213]     registering new CEC client - v6.0.2
DEBUG:   [            2214]     SetClientVersion - using client version '6.0.2'
NOTICE:  [            2214]     setting HDMI port to 1 on device TV (0)
DEBUG:   [            2214]     SetConfiguration: double tap timeout = 200ms, repeat rate = 0ms, release delay = 500ms
DEBUG:   [            2214]     detecting logical address for type 'recording device'
DEBUG:   [            2214]     trying logical address 'Recorder 1'
DEBUG:   [            2214]     << Recorder 1 (1) -> Recorder 1 (1): POLL
TRAFFIC: [            2214]     << 11
WARNING: [            2244]     Write: write failed
TRAFFIC: [            2244]     << 11
WARNING: [            2283]     Write: write failed
DEBUG:   [            2283]     >> POLL not sent
DEBUG:   [            2283]     using logical address 'Recorder 1'
DEBUG:   [            2283]     Recorder 1 (1): device status changed into 'handled by libCEC'
DEBUG:   [            2283]     Recorder 1 (1): power status changed from 'unknown' to 'on'
DEBUG:   [            2283]     Recorder 1 (1): vendor = Pulse Eight (001582)
DEBUG:   [            2283]     Recorder 1 (1): CEC version 1.4
DEBUG:   [            2283]     AllocateLogicalAddresses - device '0', type 'recording device', LA '1'
DEBUG:   [            2284]     Recorder 1 (1): osd name set to 'CECTester'
DEBUG:   [            2284]     Recorder 1 (1): menu language set to 'eng'
DEBUG:   [            2284]     using auto-detected physical address 2300
DEBUG:   [            2284]     Recorder 1 (1): physical address changed from ffff to 2300
DEBUG:   [            2284]     << Recorder 1 (1) -> broadcast (F): physical address 2300
TRAFFIC: [            2284]     << 1f:84:23:00:01
NOTICE:  [            2420]     CEC client registered: libCEC version = 6.0.2, client version = 6.0.2, firmware version = 5, logical address(es) = Recorder 1 (1) , physical address: 2.3.0.0,  compiled on 2023-06-08 00:34:30 by root@osmc on Linux 4.9.269 (armv7l), features: P8_USB, DRM, P8_detect, AOCEC
DEBUG:   [            2420]     << Recorder 1 (1) -> TV (0): OSD name 'CECTester'
TRAFFIC: [            2420]     << 10:47:43:45:43:54:65:73:74:65:72
DEBUG:   [            2704]     << requesting power status of 'TV' (0)
TRAFFIC: [            2704]     << 10:8f
DEBUG:   [            3768]     expected response not received (90: report power status)
TRAFFIC: [            3768]     << 10:8f
waiting for input
DEBUG:   [            4769]     expected response not received (90: report power status)

[AndersG]

FWIW I see the same, but not every night. Yes, I have CEC active. I normally use a small keyboard with Kodi, but it is convenient to use teh TV remote at times. I also back up the kodi config every night, but this all started when I go our new Vero V

[JimKnopf]

Have you made any progress on this since then?

[Flashback1]

No, as I had no feedback on how to turn on CEC debugging.

I’ve since found another thread - which indicates turning on component specific for the libCEC library - is this what I need to keep on permanently and then post the log every day (in case it doesn’t happen every day)?

Vero wake-up problem

At least we can collect some debug information; perhaps, we find something which explains the behaviour: To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here. Depending on the used skin you have to set the settings-level to standard or higher, in summary: enable debug logging at sett…

[JimKnopf]

Yes, this is the exact way you can try. Perhaps, we get some more information for this scenario with this action. Since you don’t suffer from a hang/crash, you only need to transfer the debug log set when you find your TV active the next day/in morning without a reboot; by that way we also should have the matching system journal. Don’t forget to also provide the CEC config as descriped in this post. Thx.

PS: The times when you last switched off your TV and when you you’ve found your TV unexpected active are also nice to have.

[Flashback1]

Do I need to turn on debug logging, or can I just turn on the component-specific logging? It allows me to do the latter as verbose, without turning on debug logging, but not sure if it’ll capture those events or not. I’ve turned on debug logging for now, although I have just missed the window today.

CEC config is here: https://paste.osmc.tv/ofenebidep

I’m not sure how workable this logging will be though, other than to enable it every night and then check in the morning. Both my AVR + TV are set to power off after 30 minutes / 2 hours, so usually I don’t / won’t know when it happens as I’m usually asleep (tonight aside!).

Turning off those power saving features is maybe an option, but….. we’ve all seen the price of electricity these days!

[JimKnopf]

@Flashback1

I’ve turned on debug logging for now

@Flashback1

other than to enable it every night and then check in the morning.

I think that’s the way to go.

[Flashback1]

Is thee something in particular in the log I should look for? I assume there will be some timestamped events somewhere. By sheer (bad) luck last night, I was up doing some other work so sat in the room with the TV; it didn’t auto turn on. Doh.

[JimKnopf]

@Flashback1

Is thee something in particular in the log I should look for

No, just upload the debug logs once it has happened again and you find the TV running in the morning.

[Shieldie]

My Samsung tv used to do this until I disabled Samsung SmartThings (or something like that) app from my new Samsung phone. Apparently the app polled Samsung devices in the wee hours and fired the tv up.

[grahamh]

Yesterday I connected an Android box to my TV and the setup routine asked me if I wanted to control the TV. Out of interest I chose ‘yes’ and it asked for the make of the TV. Now when I turn off any connected device or even restart Kodi (annoyingly) the TV turns off.

I suspect you need to look at the settings on your TV rather than the Vero. Though it’s still a mystery why it would turn on.

[Flashback1]

Just to note I’m no further in progressing troubleshooting on this one, but as a result of poor sleep lately the few nights I’ve been awake around the usual time I haven’t noticed it turn on, so the mystery remains! LG OLED, Samsung phone….. couldn’t find any obvious settings to check/change.

[Flashback1]

OK, so it just happened again this morning at 3.43. I presume there’s nothing in any other logs I can check (without debugging mode being on)?

I had a look at all log entries in journalctl over the past hour and excluded those that were before 3.42 (as it was at least half an hour before, so no relation most likely) and logs are here: osmc journalctl - Pastebin.com

I noticed this entry and wonder if this is a clue to what is causing it?

Jul 09 03:42:40 osmc kernel: cectx fe044000.aocec: CEC framework ctrl disabled
Jul 09 03:42:40 osmc kernel: cectx fe044000.aocec: CEC framework ctrl enabled

I’m also not sure if this gives any hint? Is it suggesting an issue with the cable?
Jul 09 03:42:43 osmc kernel: EARC fe333800.earc: HDMITX cable is plugout
Jul 09 03:42:43 osmc kernel: hdmitx: system: update rx hdr info 0
Jul 09 03:42:43 osmc kernel: hdmitx: system: plugout
Jul 09 03:42:43 osmc kernel: hdmitx: hdmitx_set_drm_pkt: disable drm pkt
Jul 09 03:42:43 osmc kernel: hdmitx: TV not support DV, clr dv_vsif
Jul 09 03:42:43 osmc kernel: hdmitx: hdmitx: H14b VSIF, switching signal to SDR
Jul 09 03:42:43 osmc kernel: hdmitx: hdmitx_set_hdr10plus_pkt: null vsif
Jul 09 03:42:43 osmc kernel: [RX]-up_phy_addr = 0
Jul 09 03:42:43 osmc kernel: hdmitx: system: update physical size: 16 9
Jul 09 03:42:43 osmc kernel: hdmitx: system: irq 80000002 0
Jul 09 03:42:43 osmc kernel: EARC fe333800.earc: HDMITX cable is plugin
Jul 09 03:42:44 osmc kernel: hdmitx: system: plugin

Given it tends to happen around the same time (when it does happen), is it some process that osmc is triggering to check/reinitialise the HDMI/CEC connection? Reinitiliase the HDMI output? If it was an issue with the cable, I’d expect it to happen at more random times, for example.

A few other extracts from various of logs that may help identify where in the chain thiis is occuring (Vero V, Marantz AVR, LG TV).

grep -iE ‘mode change|refresh rate|cec|wakeup|wake|sleep|idle|screensaver|resume|suspend|standby|playback’ /home/osmc/.kodi/temp/kodi.log

2026-07-09 03:42:41.653 T:28213    info <general>: Toggle standby state is waking
2026-07-09 03:42:41.653 T:28213    info <general>: CApplication::ToggleStandby -- Toggle TMDS clock to 1
2026-07-09 03:42:41.701 T:28213    info <general>: CApplication::ToggleStandby -- Toggle LED brightness to 1
2026-07-09 03:42:41.701 T:28213    info <general>: CApplication::ToggleStandby -- HPD locking will now be hpd_lock0
2026-07-09 03:42:41.701 T:28213    info <general>: CApplication::ToggleStandby -- checking for existence of /home/osmc/.kodi/userdata/wake.py
2026-07-09 03:51:30.971 T:2941     info <general>: Activating standby mode

This returned nothing (i.e., the last log entry was around 1am).

grep -iE ‘Starting Kodi|OpenFile|Player|VideoPlayer|Playback|Adjust display refresh rate’ /home/osmc/.kodi/temp/kodi.log

I also found this entry in journalctl interesting, is that pointing to some issue also with writing (and therefore reading from) the edid file?

Jul 09 03:43:02 osmc kernel: hdmitx: [load_edid_data] failed to open file: |/lib/firmware/edid|

In a sense, I think we can rule out the TV as these logs show the interaction is only between the Vero V and the Marantz AVR?

[JimKnopf]

This information isn’t very helpful to me. You can only see CEC activities—if they are indeed the trigger—by having debug logging enabled as discussed above.

I have a hunch, and you could simply try the following:

In the menu settings -> system -> input -> peripherals -> CEC adapter

set Devices to power on during startup to none and perhaps deactivate switch source to this device on startup. In the example screenshots all other settings are default;s only touch the both mentioned flags.

Please report what has changed for you as a result.

[JimKnopf]

Wake devices when deactivating the screensaver is another feature you should disable for now.

[Flashback1]

OK, as soon as I turned off Switch source to this device on startup I lost CEC control completely via the TV remote (so had to switch to using Yatse on my phone). Turning back on didn’t give control back, so I turned everything off (shutdown Vero V and started again) and when it started up it turned the TV back on again. This time, when I turned it off, the AVR auto switched from the current input back to my default TV input (thus losing the signal) and the TV remote was working again.

When I switched the AVR back to the Vero V input, I could go back one menu level, but then got stuck there and couldn’t go any further using the TV remote (the AVR remote didn’t do anything also), so had to go back to using Yatse. This time I left Switch source to this device on startup disabled and shutdown, turned on again and this time when the Vero V started it didn’t auto switch on the AVR (as expected, I suppose). Then when I turned the TV back on and selected the Vero V input on the AVR, I regained control using the TV remote again.

I switched to TV and the AVR switched to the TV input, then switched back to the Vero and the AVR switched to the right input.

I note also my settings are slightly different, for When the TV is switched off mine is set to ‘Suspend’ whereas yours is set to ‘Ignore’; but I think that’s fine as that is what should happen? i.e., when the TV is turned off the Vero goes into sleep mode.

I have now also changed Devices to power on during startup from ‘TV’ to ‘None’ and unchecked Wake devices when deactivating the screensaver.

I shall continue to monitor.

[darwindesign]

@Flashback1

so I turned everything off (shutdown Vero V and started again)

When CEC starts acting up it is generally optimal to power off ALL CEC enabled devices fully (ie pull the power plug from the wall for a few seconds) which resets all the CEC device assignments and forces renegotiations.

[Flashback1]

Indeed. Seems to be working as expected for now, so will monitor and see how that goes.