openbase / bco.app Goto Github PK

Maybe this logs delivers some hints about the real issue. At least once the cloud connector detects the missing connection, those is successfully reestablished. Maybe we need just to activate TCP keep alive pinging to stabilize the connection.

Or maybe the 02:49:02.096 [EventThread] WARN o.o.b.a.c.SocketWrapper Could not perform sync for user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a]: "400: Request contains an invalid argument." is causing the disconnect but in this case we need more logging to detect the invalid argument.

0:10:23.545 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a] disconnected
00:10:24.150 [EventThread] INFO  o.o.b.a.c.SocketWrapper Attempt to reconnect socket of user e9df6579-d1d9-4a8c-a24d-af93d0024e9a
00:10:24.151 [EventThread] INFO  o.o.b.a.c.SocketWrapper Reconnection event for user e9df6579-d1d9-4a8c-a24d-af93d0024e9a
00:10:24.518 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user e9df6579-d1d9-4a8c-a24d-af93d0024e9a reconnected!
00:10:24.598 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a] connected
00:10:24.970 [EventThread] INFO  o.o.b.a.c.SocketWrapper Logged in [e9df6579-d1d9-4a8c-a24d-af93d0024e9a] successfully
00:10:25.348 [EventThread] WARN  o.o.b.a.c.SocketWrapper Could not perform sync for user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a]: "400: Request contains an invalid argument."
02:48:53.954 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a] disconnected
02:48:54.861 [EventThread] INFO  o.o.b.a.c.SocketWrapper Attempt to reconnect socket of user e9df6579-d1d9-4a8c-a24d-af93d0024e9a
02:48:54.862 [EventThread] INFO  o.o.b.a.c.SocketWrapper Reconnection event for user e9df6579-d1d9-4a8c-a24d-af93d0024e9a
02:49:01.267 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user e9df6579-d1d9-4a8c-a24d-af93d0024e9a reconnected!
02:49:01.367 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a] connected
02:49:01.697 [EventThread] INFO  o.o.b.a.c.SocketWrapper Logged in [e9df6579-d1d9-4a8c-a24d-af93d0024e9a] successfully
02:49:02.096 [EventThread] WARN  o.o.b.a.c.SocketWrapper Could not perform sync for user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a]: "400: Request contains an invalid argument."
05:51:05.772 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a] disconnected
05:51:06.369 [EventThread] INFO  o.o.b.a.c.SocketWrapper Attempt to reconnect socket of user e9df6579-d1d9-4a8c-a24d-af93d0024e9a
05:51:06.372 [EventThread] INFO  o.o.b.a.c.SocketWrapper Reconnection event for user e9df6579-d1d9-4a8c-a24d-af93d0024e9a
05:51:06.760 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user e9df6579-d1d9-4a8c-a24d-af93d0024e9a reconnected!
05:51:06.863 [EventThread] INFO  o.o.b.a.c.SocketWrapper Socket of user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a] connected
05:51:07.233 [EventThread] INFO  o.o.b.a.c.SocketWrapper Logged in [e9df6579-d1d9-4a8c-a24d-af93d0024e9a] successfully
05:51:07.709 [EventThread] WARN  o.o.b.a.c.SocketWrapper Could not perform sync for user[e9df6579-d1d9-4a8c-a24d-af93d0024e9a]: "400: Request contains an invalid argument."

The Google Home team just announced the introduction of an OpenClose trait:

• https://developers.google.com/actions/smarthome/traits/openclose#request

It can even be configured to only support querying the state! It can probably be mapped to the following BCO states:

• BlindState
• ContactState
• DoorState
• WindowState

Params: unitId,servicetype,timestart,timeend,
return : average

If openHAB is restarted will the app is running it does not recover from the connection loss.

Some devices which have separate classes in our system are of the same thing type in openHAB. An example for this are the Philips hues generation 1 and 3.
So in these cases it is not possible to decide for which of these classes a device should be registered.
It is possible to just chose one but that makes config synchronization with old bco configuration harder.

Labels should also be saved when storing data in influx

Please fix and activate test again after the PowerStateSynchroniser has been fixed as well.

Currently only updates from openHAB things are synchronized to BCO. This has to be enhanced by also handling item changes and synchronizing changes from BCO to OpenHAB2.
For example if a device is removed and label changes or location changes are applied.

The Google Assistant supports two-factor authentication by either making sure that the request should really be performed or asking for a pin:

• https://developers.google.com/actions/smarthome/two-factor-authentication#response

This could be configurable for certain services and units.

Currently the project can only be build by installing openHAB 2.0 locally. The needed dependencies should be made available.

Currently the sync request does not work anymore, because the API for it has changed.
Therefore, the configuration used by the Google Assistant cannot be updated anymore.

Before the API change a unique id was added as a query parameter to the sync request uri to identify the action.
We added this id as a secure parameter for our heroku application.

With the new API the owner of the action has to generate a service account key.
I guess this key is then used for oath authentication.
The actions-on-google npm package provides an easy way to make sync request with this key.

So, I think the solution to this problem is as follows:

1. Generate the service account key for the BCO action
2. Add the json content of the generated key file as a secure heroku parameter
3. User the package by google with this parameter to make the sync request

If the app is started when openHAB is not running the exception thrown because the connection cannot be established are not handled.
Issue #4 is related to this one.

Maybe we should just skip such updates to avoid mapping errors.

15:52:11.420 [pool-1-thread-619] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.420 [pool-1-thread-619] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.421 [pool-1-thread-639] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.421 [pool-1-thread-639] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.427 [pool-1-thread-661] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.429 [pool-1-thread-661] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.430 [pool-1-thread-665] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.430 [pool-1-thread-665] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.434 [pool-1-thread-619] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.435 [pool-1-thread-619] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.434 [pool-1-thread-639] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.436 [pool-1-thread-639] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.443 [pool-1-thread-51] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.444 [pool-1-thread-51] ERROR o.o.b.a.c.FulfillmentHandler =====================================
15:52:11.446 [pool-1-thread-627] ERROR o.o.b.a.c.FulfillmentHandler ═══⚀ Could not map [PowerState, UNKNOWN] to jsonObject
15:52:11.447 [pool-1-thread-627] ERROR o.o.b.a.c.FulfillmentHandler =====================================