Freeboard 的 Orion 数据源与 Context Broker 之间没有连接
No connection between Freeboard's data source for Orion and Context Broker
我一直在尝试连接 Freeboard 以可视化来自 OCB 的上下文信息，但是遇到了阻止我从那里接收任何数据的困难。我的想法是 Freeboard 连接到 OCB 有问题，因为在 OCB 的订阅列表中没有任何新条目，而 Freeboard 中的数据源显示它从未更新过。
OCB 作为 docker 容器打开。 docker 主机中的干舷 运行。
我尝试通过以下方式将 ip 设置为从 docker 中提取的 ip：
sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' orion1
它给了我 172.17.0.3，但它也没有用。我想无论如何都不应该，因为我可以通过 localhost:1026 与 OCB 通信，只要我通过 cUrl 或 Insomnia 进行通信即可。我可以推送新实体、更新等等。
一直没有正常工作的积累服务器（）现在可以了。但问题是，我自己添加订阅，不能 运行 本地主机（环回接口）上的 acc 服务器，而是在其他可用接口上，然后将该接口的 ip 添加到我发送给 OCB 的订阅负载.也许某处与 Freeboard 有冲突。
此处的问题与缺乏 CORS 支持有关。对此的简单解决方案是在启动 Orion Context Broker 时启用 CORS 功能，如 here 所述。
我对这个主题进行了相当多的（实际上是不必要的）研究，并针对此 github post 中描述的问题提出了过度的解决方案。有一种代理服务器方法可以解决这个问题。我想提议为 Orion Context Broker 添加 CORS 支持，当发现它已经实现时我感到非常惊讶。
不过，我有两个要求。我想 @fgalan 现在是一个合适的人选，涉及 OCB 和外围软件的后端和文档。
能否更加强调 CORS 和 ACCESS-CONTROL-ALLOW-ORIGIN 解决方案？其背后的原因是它在 OCB 和互联网浏览器中的任何前端应用程序或站点（即 Freeboard）运行 之间提供了无缝连接。它不应该隐藏得太深以至于我在寻找其他东西时偶然发现了我的问题的解决方案。我想把它放在我不知道其他可见位置的一些演练文档中。问题是我花了两个星期的时间试图解决它，毕竟在我眼皮底下寻找了过度和不必要的解决方案，而简单易用的解决方案就在眼前。好消息是我在堆栈和 git 上有很好的连接，所以它得到了解决。可能有人在使用 Freeboard 时出现任何问题后就放弃了。很遗憾，因为目前没有比 Freeboard 更好的可视化开源软件了。问题不仅在于 Freeboard，正如我所说，它涉及更多的前端应用程序和解决方案。按照我们FIWARE的思维方式，这些事情应该以不同的方式解决。
Freeboard 的 FIWARE 数据源插件目前一文不值。正如@fgalan 在评论中指出的那样，它是为 v1 版 Orion Context Broker API 开发的，尚未更新。因此，它比它想象的要复杂得多。正如 OCB 的文档所指出的那样，v1 方法并不是真正的 RESTfull。在对 Freeboard 的 OCB 插件进行了简短的代码审查后，我可以说这不值得使用。据我所知它应该仍然有效，因为 OCB 允许执行 v1 请求（但它对我不起作用），这些请求已被弃用。在我看来，关于主题的新 post 应该出现（不确定我应该联系谁），因为 this 有点误导。使用已弃用的软件并传播与 OCB 交互的不良习惯有什么意义？
我认为解决这个问题很简单。只需在 Freeboard 中使用 JSON 数据源。我了解在 2015 年为 Freeboard 创建个人数据源插件背后的动机，当时还没有 OCB API 的 RESTfull v2 版本，但现在有一个，为什么不使用它呢？自从摆脱了 CORS 的困难之后，我就一直在使用它，在我看来它工作得很好。正如我之前所说，Freeboard 提供了很好的机会，同时易于设置和维护。它不应该那么容易被抛弃。
通过在 Freeboard 中对 JSON 有效负载使用 GET 请求，现在我们可以完全访问 OCB 中的上下文查询。它不需要任何 POST 方法，只要我们按预期使用 Freeboard（通过查询数据进行可视化）即可。投入
?options=keyValues
到请求的 URL，我们已经获得了一种非常智能和紧凑的方式来可视化来自 Broker 的数据。
这正是我认为应该解决的方式。在我看来，2015 年关于该主题的最新更新还不够，特别是如果开发了更好的方法来从 OCB 访问上下文数据。
我一直在尝试连接 Freeboard 以可视化来自 OCB 的上下文信息，但是遇到了阻止我从那里接收任何数据的困难。我的想法是 Freeboard 连接到 OCB 有问题，因为在 OCB 的订阅列表中没有任何新条目，而 Freeboard 中的数据源显示它从未更新过。
OCB 作为 docker 容器打开。 docker 主机中的干舷 运行。
我尝试通过以下方式将 ip 设置为从 docker 中提取的 ip：
sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' orion1
它给了我 172.17.0.3，但它也没有用。我想无论如何都不应该，因为我可以通过 localhost:1026 与 OCB 通信，只要我通过 cUrl 或 Insomnia 进行通信即可。我可以推送新实体、更新等等。
一直没有正常工作的积累服务器（
此处的问题与缺乏 CORS 支持有关。对此的简单解决方案是在启动 Orion Context Broker 时启用 CORS 功能，如 here 所述。
我对这个主题进行了相当多的（实际上是不必要的）研究，并针对此 github post 中描述的问题提出了过度的解决方案。有一种代理服务器方法可以解决这个问题。我想提议为 Orion Context Broker 添加 CORS 支持，当发现它已经实现时我感到非常惊讶。
不过，我有两个要求。我想 @fgalan 现在是一个合适的人选，涉及 OCB 和外围软件的后端和文档。
能否更加强调 CORS 和 ACCESS-CONTROL-ALLOW-ORIGIN 解决方案？其背后的原因是它在 OCB 和互联网浏览器中的任何前端应用程序或站点（即 Freeboard）运行 之间提供了无缝连接。它不应该隐藏得太深以至于我在寻找其他东西时偶然发现了我的问题的解决方案。我想把它放在我不知道其他可见位置的一些演练文档中。问题是我花了两个星期的时间试图解决它，毕竟在我眼皮底下寻找了过度和不必要的解决方案，而简单易用的解决方案就在眼前。好消息是我在堆栈和 git 上有很好的连接，所以它得到了解决。可能有人在使用 Freeboard 时出现任何问题后就放弃了。很遗憾，因为目前没有比 Freeboard 更好的可视化开源软件了。问题不仅在于 Freeboard，正如我所说，它涉及更多的前端应用程序和解决方案。按照我们FIWARE的思维方式，这些事情应该以不同的方式解决。
Freeboard 的 FIWARE 数据源插件目前一文不值。正如@fgalan 在评论中指出的那样，它是为 v1 版 Orion Context Broker API 开发的，尚未更新。因此，它比它想象的要复杂得多。正如 OCB 的文档所指出的那样，v1 方法并不是真正的 RESTfull。在对 Freeboard 的 OCB 插件进行了简短的代码审查后，我可以说这不值得使用。据我所知它应该仍然有效，因为 OCB 允许执行 v1 请求（但它对我不起作用），这些请求已被弃用。在我看来，关于主题的新 post 应该出现（不确定我应该联系谁），因为 this 有点误导。使用已弃用的软件并传播与 OCB 交互的不良习惯有什么意义？
我认为解决这个问题很简单。只需在 Freeboard 中使用 JSON 数据源。我了解在 2015 年为 Freeboard 创建个人数据源插件背后的动机，当时还没有 OCB API 的 RESTfull v2 版本，但现在有一个，为什么不使用它呢？自从摆脱了 CORS 的困难之后，我就一直在使用它，在我看来它工作得很好。正如我之前所说，Freeboard 提供了很好的机会，同时易于设置和维护。它不应该那么容易被抛弃。
通过在 Freeboard 中对 JSON 有效负载使用 GET 请求，现在我们可以完全访问 OCB 中的上下文查询。它不需要任何 POST 方法，只要我们按预期使用 Freeboard（通过查询数据进行可视化）即可。投入
?options=keyValues到请求的 URL，我们已经获得了一种非常智能和紧凑的方式来可视化来自 Broker 的数据。
这正是我认为应该解决的方式。在我看来，2015 年关于该主题的最新更新还不够，特别是如果开发了更好的方法来从 OCB 访问上下文数据。