This repository contains all core apps which are a part of the bco main distribution. By this each app is provided within its own folder directly containing the source code or linking to an external repository via git submodule.
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."
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.
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.
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:
Generate the service account key for the BCO action
Add the json content of the generated key file as a secure heroku parameter
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.