我一直在尝试连接 Freeboard 以可视化来自 OCB 的上下文信息，但是遇到了一些困难，导致我无法从那里接收任何数据。我的想法是，将Freeboard连接到OCB有问题，因为在OCB的订阅列表中没有任何新条目，并且Freeboard中的数据源显示它从未更新过。
OCB 作为 docker 容器打开。 Freeboards 在 docker 主机中运行。
我尝试将 ip 设置为从 docker 中提取的 ip：
sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' orion1
它给了我 172.17.0.3，但它也不起作用。我想无论如何都不应该有，因为只要我通过 cUrl 或 Insomnia 进行操作，我就可以通过 localhost:1026 与 OCB 进行通信。我可以推送新实体、更新等等。
尚未运行的累积服务器（链接在这里 https://stackoverflow.com/questions/49458811/accumulation-server-no-action）现在还可以。但问题是，我自己添加订阅，无法在本地主机（环回接口）上运行 acc 服务器，而是在其他可用接口上运行，然后将该接口的 ip 添加到我发送给 OCB 的订阅负载中。也许某处与 Freeboard 发生冲突。
这里的问题与缺乏 CORS 支持有关。解决此问题的简单解决方案是在启动 Orion Context Broker 时启用 CORS 功能，如下所述here https://fiware-orion.readthedocs.io/en/master/user/cors/index.html.
我对这个主题进行了相当多的（实际上不必要的）研究，并为本文中描述的问题提出了过度的解决方案github 帖子 https://github.com/telefonicaid/fiware-orion/issues/3239。有一种代理服务器方法可以解决该问题。我想提议向 Orion Context Broker 添加 CORS 支持，当发现它已经实现时，我感到很惊讶。
有类似的帖子this https://github.com/Freeboard/freeboard/issues/85, and this https://github.com/Freeboard/freeboard/issues/208这对破案很有帮助。
但是，我有两个请求。我想 @fgalan 现在是一个关于 OCB 和外围软件的后端和文档的人选。
是否可以更加强调 CORS 和 ACCESS-CONTROL-ALLOW-ORIGIN 解决方案？其背后的原因是，它在 OCB 和任何在互联网浏览器中运行的前端应用程序或站点（即 Freeboard）之间提供了无缝连接。它不应该如此隐藏，以至于我在寻找其他东西时偶然发现了我的问题的解决方案。我想把它放在一些演练文档中我不知道其他一些可见的地方。问题是我花了两周的时间试图解决它，但最终还是选择了过度且不必要的解决方案，而简单易用的解决方案就在我眼皮子底下。好消息是我在 stack 和 git 上有很好的连接，所以问题就解决了。可能有人在经历了任何失误后就放弃了 Freeboard。这是一种耻辱，因为目前没有比 Freeboard 更好的可视化开源软件。问题不仅仅在于 Freeboard，正如我所说，它还涉及更多的前端应用程序和解决方案。当我们遵循 FIWARE 的思维方式时，这些问题应该以不同的方式解决。
-
Freeboard 的 FIWARE 数据源插件目前一文不值。正如 @fgalan 在评论中指出的那样，它是为 Orion Context Broker API v1 版本开发的，尚未更新。因此，它比想象的要复杂得多。正如 OCB 文档所指出的，v1 方法并不真正像 RESTfull。在对 Freeboard 的 OCB 插件进行简短的代码审查后，我可以说这不值得使用。据我了解它应该仍然有效，因为 OCB 允许进行 v1 请求（但无论如何它对我不起作用），这些请求已被弃用。在我看来，应该出现有关该主题的新帖子（不确定我应该联系谁），因为this https://www.fiware.org/2015/07/13/fiware-orion-data-source-now-available-for-freeboard/有点误导。使用已弃用的软件并传播与 OCB 交互的坏习惯有什么意义？
我认为这个问题的解决方案很简单。只需在 Freeboard 中使用 JSON 数据源即可。我理解 2015 年为 Freeboard 创建单独数据源插件的动机，当时还没有 RESTfull v2 版本的 OCB API，但现在有了一个，为什么不使用它呢？从那以后我就使用了 CORS，摆脱了它的困难，在我看来它效果很好。正如我之前所说，干舷提供了巨大的机会，同时易于设置和维护。它不应该那么容易被放弃。
通过在 Freeboard 中使用 GET 请求 JSON 负载，现在我们可以完全访问 OCB 中的上下文查询。只要我们按预期使用 Freeboard（通过查询数据进行可视化），它就不需要任何 POST 方法。投放
?options=keyValues
到请求的 URL，我们已经获得了一种非常智能且紧凑的方式来可视化来自代理的数据。
我认为这就是解决问题的方式。在我看来，2015 年关于这个主题的最后一次更新还不够，特别是如果开发出更好的方法来访问 OCB 的上下文数据的话。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
