[RELEASE] OwnTracks for Hubitat Presence Detection

⚙️ Custom Apps and Drivers
, ,
3235

I have been seeing issues Owntracks lately I have everything. I use DNS Adguard and some other stuff I have for security and I can not seem to get this working consistently.

I have getting in my logs android. Although iOS devices are having issues too.

Summary

DefaultDispatcher-worker-5] MessageProcessor: Received incoming message: MessageCmd on NOKEY with id=438db9ca
2024-12-22 16:06:28.699 W [main] MapViewModel: no location available
2024-12-22 16:06:38.807 W [DefaultDispatcher-worker-7] MessageProcessor: Error sending message [MessageLocation id=c5aedb81 ts=2024-12-22T21:06:23Z,lat=40.1879611,long=-74.2605506,created_at=2024-12-22T21:06:28.788Z,trigger=DEFAULT]. Re-queueing
org.owntracks.android.net.MessageProcessorEndpoint$OutgoingMessageSendingException: java.net.SocketTimeoutException: timeout
at org.owntracks.android.net.http.HttpMessageProcessorEndpoint.sendMessage-gIAlu-s(SourceFile:699)
at org.owntracks.android.services.MessageProcessor.sendAvailableMessages(SourceFile:640)
at org.owntracks.android.services.MessageProcessor.access$sendAvailableMessages(SourceFile:1)
at org.owntracks.android.services.MessageProcessor$sendAvailableMessages$1.invokeSuspend(Unknown Source:11)
at kotlin.coroutines.jvm.internal.ContinuationImpl.resumeWith(SourceFile:9)
at kotlinx.coroutines.DispatchedTask.run(SourceFile:109)
at androidx.work.Worker$2.run(SourceFile:148)
at kotlinx.coroutines.scheduling.TaskImpl.run(SourceFile:3)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:93)
Caused by: java.net.SocketTimeoutException: timeout
at okio.SocketAsyncTimeout.newTimeoutException(SourceFile:5)
at okio.InputStreamSource.read(SourceFile:51)
at okio.RealBufferedSource.indexOf(SourceFile:242)
at okio.RealBufferedSource.readUtf8LineStrict(SourceFile:32)
at okhttp3.internal.connection.RouteSelector.readResponseHeaders(SourceFile:49)
at okhttp3.internal.connection.Exchange.readResponseHeaders(SourceFile:5)
at okhttp3.internal.http.CallServerInterceptor.intercept(SourceFile:255)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.connection.ConnectInterceptor.intercept(SourceFile:91)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.cache.CacheInterceptor.intercept(SourceFile:673)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.http.BridgeInterceptor.intercept(SourceFile:542)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.http.BridgeInterceptor.intercept(SourceFile:143)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(SourceFile:91)
at okhttp3.internal.connection.RealCall.execute(SourceFile:39)
at org.owntracks.android.net.http.HttpMessageProcessorEndpoint.sendMessage-gIAlu-s(SourceFile:237)
... 8 more
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.read(SocketInputStream.java:188)
at java.net.SocketInputStream.read(SocketInputStream.java:143)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(SourceFile:25)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(SourceFile:173)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.readUntilDataAvailable(SourceFile:1)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.read(SourceFile:14)
at okio.InputStreamSource.read(SourceFile:97)
at okio.InputStreamSource.read(SourceFile:24)
... 25 more

2024-12-22 16:06:38.811 I [DefaultDispatcher-worker-10] MessageProcessor$resendDelayWait: Waiting for 1s before retrying send
2024-12-22 16:06:53.965 W [DefaultDispatcher-worker-10] MessageProcessor: Error sending message [MessageLocation id=9171320a ts=2024-12-22T21:06:23Z,lat=40.1879611,long=-74.2605506,created_at=2024-12-22T21:06:28.819Z,trigger=PING]. Re-queueing
org.owntracks.android.net.MessageProcessorEndpoint$OutgoingMessageSendingException: java.net.SocketTimeoutException: timeout
at org.owntracks.android.net.http.HttpMessageProcessorEndpoint.sendMessage-gIAlu-s(SourceFile:699)
at org.owntracks.android.services.MessageProcessor.sendAvailableMessages(SourceFile:640)
at org.owntracks.android.services.MessageProcessor.access$sendAvailableMessages(SourceFile:1)
at org.owntracks.android.services.MessageProcessor$sendAvailableMessages$1.invokeSuspend(Unknown Source:11)
at kotlin.coroutines.jvm.internal.ContinuationImpl.resumeWith(SourceFile:9)
at kotlinx.coroutines.DispatchedTask.run(SourceFile:109)
at androidx.work.Worker$2.run(SourceFile:148)
at kotlinx.coroutines.scheduling.TaskImpl.run(SourceFile:3)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:93)
Caused by: java.net.SocketTimeoutException: timeout
at okio.SocketAsyncTimeout.newTimeoutException(SourceFile:5)
at okio.InputStreamSource.read(SourceFile:51)
at okio.RealBufferedSource.indexOf(SourceFile:242)
at okio.RealBufferedSource.readUtf8LineStrict(SourceFile:32)
at okhttp3.internal.connection.RouteSelector.readResponseHeaders(SourceFile:49)
at okhttp3.internal.connection.Exchange.readResponseHeaders(SourceFile:5)
at okhttp3.internal.http.CallServerInterceptor.intercept(SourceFile:255)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.connection.ConnectInterceptor.intercept(SourceFile:91)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.cache.CacheInterceptor.intercept(SourceFile:673)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.http.BridgeInterceptor.intercept(SourceFile:542)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.http.BridgeInterceptor.intercept(SourceFile:143)
at okhttp3.internal.http.RealInterceptorChain.proceed(SourceFile:124)
at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(SourceFile:91)
at okhttp3.internal.connection.RealCall.execute(SourceFile:39)
at org.owntracks.android.net.http.HttpMessageProcessorEndpoint.sendMessage-gIAlu-s(SourceFile:237)
... 8 more
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.read(SocketInputStream.java:188)
at java.net.SocketInputStream.read(SocketInputStream.java:143)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(SourceFile:25)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(SourceFile:173)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.readUntilDataAvailable(SourceFile:1)
at org.conscrypt.ConscryptEngineSocket$SSLInputStream.read(SourceFile:14)
at okio.InputStreamSource.read(SourceFile:97)
at okio.InputStreamSource.read(SourceFile:24)
... 25 more

2024-12-22 16:06:53.970 I [DefaultDispatcher-worker-1] MessageProcessor$resendDelayWait: Waiting for 1s before retrying send
2024-12-22 16:06:59.106 I

I don't know where to go from here.
I'm going to try to squeeze in a screenshot here.

1000002772
10000027721920×1837 397 KB

3236

Are you running the .139 - .141 Beta Hub software? I was seeing that and had to roll back to .138. I was getting the "too many events" error in the Hubitat logs as well.

When the hub throws the error, the Mobile app doesn't get a response that the location went through so it reschedules it again, and then drama repeats.

3237

I need to look at that. It shouldn't be tossing the error.

1 Like
3238

Thank for that. I don't want revert if this will be resolved soon.. I think I have workaround for now to get my users presence detection working.

3239

Do we know if .142 fixes these issues? My presence has gone wonky last few days and wasn’t sure if it’s the Hubitat software of the latest changes to Owntracks. All my devices seem to have events queued up to send and seeing timeouts and other issues sending.

3240

Don't think I see a mention. 2.4.0.242 was likely locked down before the fix for this was implemented.

3241

Same, but only Apple devices. I blame iOS 18.

3242

I'm seeing this on Android and iOS. They haven't gone to 18 yet, either. I'm the only Android in the house.

3243

It's the Hubitat SW issue. Hopefully addressed in .143.

5 Likes
3244

I see .143 is out now. Fingers crossed

3245

Doesn't look good. I still see the same issue.

3246

@gopher.ny - are you aware of this issue?

3247

Agreed. Looks no different

3248

Can you PM me the hub id where this happens? I'll take a look.
Please ignore the error in the meantime (as long as thing work).

3249

Oh man.. whats up now. Locations are all over. Also location updates are really slow.

1 Like
3250

I updated my hubs to .143 this morning and figured out our owntracks presence is fubared.

Anything to do, or waiting for an update at this point?

1 Like
3251

@lpakula can you provide this to @gopher.ny? I have not updated my hub yet, so I'm not seeing the errors in my logs.

3252

I'm on 143.

My dashboard tiles are messed up. If I get my tile to display correctly, my wife's tile says no response from hub. If hers is working, mine isn't. The Map tile that shows both of us seems to always say no response from hub. It looks like the phones are talking to hub ok though as I can see our travels in the events.

I have not begun to troubleshoot this yet just posting here in case someone else has similar issues.

1 Like
3253

I'm noticing in the owntracks app on the phone it'll timeout with a bunch of updates in queue.

We left today to go to a friend's a couple times and it seems like one of our phones would update okay and the other would timeout.

I edited my post. I'm actually on .143 as well.

1 Like
3254

I am having Owntraks Presence issues
Currently on .143

My amdroid is okay
Wifes ios is not reporting correctly from owntracks

I did a rollback to a previous working version

No luck

My OT is all Busted Up Broken now