I am working on IoT using IBM Watson. I am able to successfully send the built-in action for Reboot/Reset, from the console to esp8266. However, when I try to send the reboot command from NodeRed application to esp8266, it does not work. Where am I going wrong?
Here is my NodeRed application snapshot Node Red Application
Also below is the configuration of each node
IBM Watson IoT configuration Node
IBM Watson Inject Node
My device code is exactly the same as esp8266 as managed device except the few config parameters like Device Id and Device Type and Wifi credentials.
Your red triangle on your IOT node suggests a configuration error, which means that the node is not able to connect to the IOT server. Check the node configuration - the pencil for the api key and scroll down for rest of the panel you show - to remove the red triangle.
Once you have got rid of the red triangle and you are still not seeing any commands sent, and you have followed the set-up instructions then it may be that you are missing the security settings step. On the Watson IOT platform select security > policies > connection security Then set the appropriate option.
Related
I am new to FIWARE. I managed to install Orion Context Broker on my local system following the steps mentioned in the FIWARE website. I am able to use CURL commands to create entities and also retrieve values.
I have also installed Wirecloud on my local system and able to access Wirecloud UI from my browser.
But I am unable to display the entities on the Wirecloud widgets. I have tried all widgets including "NGSI Type Browser", NGSI Browser and NGSI Source operator.
All returning the same error: "ConnectionError: Unexpected response from WireCloud's proxy"
Please help me on how to proceed. My NGSI-proxy is also running and listening on port 3000. Screenshots attached.
enter image description here
Can you try to replace localhost with IP address of your machine running Orion and Ngsiproxy?
I am trying to setup a websocket connection to the Kubernetes Pod Exec API, based on the suggestions given in this SO post: How to execute command in a pod (kubernetes) using API?.
Here's what I have done so far -
Installed Simple Web Socket Client extension in Chrome.
Started kubectl proxy --disable-filter=true to run proxy with WS connections allowed. kubectl.exe version is 1.8.
Used address ws://localhost:8001/api/v1/namespaces/default/pods/nginx-3580832997-26zcn/exec?container=nginx&stdin=1&stdout=1&stderr=1&tty=1&command=%2Fbin%2Fsh in the Chrome extension to connect to the exec api.
When I click connect, Chrome reports back an error with the message -
Error during WebSocket handshake: Response must not include 'Sec-WebSocket-Protocol' header if not present in request
Apparently, kubectl is sending back empty Sec-WebSocket-Protocol header in the response and Chrome is taking offense to that.
I tried changing the code of Simple Web Socket Client open method to send empty protocols parameter to the Websocket client creation call, like - ws = new WebSocket(url, []); to coax Chrome in sending empty header in request, but Chrome doesn't send empty header.
So what can be done to directly connect to the exec in Chrome?
This is a known issue; kubectl proxy does not support websockets. (You can verify this easily by starting up kubectl proxy and then attempting kubectl --server=http://127.0.0.1:8001 exec ...; you will receive the message error: unable to upgrade connection: <h3>Unauthorized</h3> if the filter is enabled and Error from server (BadRequest): Upgrade request required if the filter is disabled).
The confusion might come from the fact that the kube-apiserver proxy does support websockets, but that proxy is different from the kubectl proxy.
As I see you have 3 options now (in order of difficulty):
Access kube-apiserver directly. You will likely need authentication that kubectl proxy is handling for you now
Use SockJS, this is what Kubernetes Dashboard does for the exec feature
Fix #25126
After reading the code in https://github.com/kubernetes-ui/container-terminal/blob/master/container-terminal.js, found that exec uses base64.channel.k8s.io protocol. The Simple Web Socket Client code wouldn't have worked because of this and also that the stream communication is in base64, not plain text.
Leaving this as an answer for other folks trying to implement a WS based terminal emulator... as #janos-lenart mentioned, the code is pretty new and there may be issues using it in different browsers, best bet at this point is to read example code and start from there.
I've recently created a Mule application (3.7.0 CE) on a laptop. I'm connected to an AWS RDS instance when running locally in AnyPoint Studio using Maven. I started with a local MySQL DB and migrated it to AWS because my application "proofofconcept" is just that a proof of concept and I would like to show the application online (public url) instead of my laptop for a presentation. I added the database.url=... property to the application properties when I deployed to Anypoint Runtime Manager in the cloud. I'm currently getting a:
communications link failure
I've tried several things and nothing has worked. I tried a basic database connection first in the database config. And, then I created a JDBC datasource in Spring-beans. Both methods worked locally and in-communication with AWS (remote). When I deploy to Runtime Manager, the application deploys. And, I get the console that's generated runtime by the RAML. When I call a url e.g. api/v1/orders it runs and runs and after timeout provides the communication error.
Does anyone 1) know if the communication is allowed? 2) know how to fix this? I would like to demo the POC online for my client.
Thanks in advance
My issue was with Amazon VPC and the default security group assigned to my RDS instance. By default all outbound activity is set to any protocol and any port for any ip (0.0.0.0/0). Inbound routing, however was specifying only port 3306 but also a custom using-ip that was my home network public ip. I changed the ip specification to be 0.0.0.0/0. This now mean's that any ip can send a request though port 3306 to my Amazon MySQL instance.
I'm writing an application which delivers data from remote devices over an HTTP API. These devices are on a mobile data connection and have limited resources.
I wish to receive custom monitoring data over the HTTP API, relying on the security model designed in the application, and push that data to Zabbix directly (or indirectly) from node.js. I do not wish to use Zabbix Agent on the remote devices.
I see that I can use zabbix_sender to send data to a Zabbix server containing a pre-configured host. This works great. I intend to deliver monitoring data over my custom API, and when received give this data to zabbix_sender inside the server network.
The problem is there are many devices in the field and more are being added all the time.
TL;DR:
When zabbix_sender provides a custom hostname which doesn't exist in Zabbix already, it fails.
I would like to auto-add discovered hosts, based upon new hostnames from zabbix_sender. How would I do this?
Also, extra respect if anyone can give examples of how to avoid zabbix_sender and send data directly from node.js to the Zabbix server. I mean: suggest an NPM package that you have experience using. (Update: Found working node.js package here: https://www.npmjs.com/package/node-zabbix-sender)
Zabbix configuration: I'm learning from Zabbix 2.4 installed in Docker, no custom configuration from this Dockerhub: https://hub.docker.com/r/zabbix/zabbix-2.4/
Probably the best would be to use the Zabbix API to create hosts directly.
Alternatively, you could set up an action and emulate active agent connection, which would make Zabbix create the host via the active agent auto-regstration.
You could also use low level discovery (LLD) to send in JSON, which would result in hosts/items being created, based on prototypes.
In all of these cases you have to wait for one minute (by default) for the hosts to appear in the Zabbix cache, then you can send the data.
Also note that Zabbix 2.4 is not supported anymore, it will receive no fixes - it is not a "long-term support" release.
We are experiencing the issue when trying to connect to the cluster after updating the version of Java SDK.
The setup of the system is as follows:
We have a web application that is using Java SDK and a Couchbase cluster. In between we have a VIP (Virtual IP Address). We realise that isn’t ideal but we’re not able to change that immediately since VIP was mandated by Tech Ops. VIP is basically only there to reroute the initial request on application startup. That way we can make modifications on the cluster and ensure that when application starts it can find the cluster regardless of the actual nodes in the cluster and their IPs.
Prior to the issue we used JAVA SDK version 1.4.4. Our application would start and Java SDK would initiate a request on port 8091 to VIP. Please note that port 8091 is the only port open on VIP. VIP would reroute the request to one of the node cluster currently in use the cluster would respond to Java SDK. At that point Java SDK would discover all the nodes in the cluster and application would run fine. During up time if we would add, remove a node from the cluster Java SDK would update automatically and everything would run without the issue.
In the last sprint we updated the Java SDK to version 2.1.3. Our application would start and Java SDK would initiate a request on port 11210 to VIP. Since this port is not open the request would fail and Java SDK would throw an exception:
Caused by: java.lang.RuntimeException: java.util.concurrent.TimeoutException
at com.couchbase.client.java.util.Blocking.blockForSingle(Blocking.java:93)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:108)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:99)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:89)
No further request would be made on any port.
It appears the order in which port are being used has been changed between versions. Could somebody please confirm, or dispute, that the order in which ports are being used for cluster discovery has been changed between versions. Also could somebody please provide some advice on how we could resolve the issue. We are trying to understand the clients behavior, if we could open all those ports on the VIP would the client still then function correctly and at full performance?
The issue is happening on our production environment which we cannot use for testing out potential solutions since it will interfere with our products.
In v2.x of the Java SDK, it defaults to 11210 to get the cluster map to bootstrap the application. This is a huge improvement actually as now the map comes from the managed cache and not the cluster manager (8091). The SDK should use 8091 as a fall back if it cannot get the map on 11210 though. Regardless, you really want to get that map from 11210, trust me. It cleans up a lot of problems.
To resolve this long term and follow Couchbase best practices, upgrade to the Java 2.2.x SDK, get rid of the VIP entirely and go with a DNS SRV record instead. That gives you one DNS entry for the SDK connection object and you just manage the node list in DNS. It works great. I say SDK 2.2 as the DNS SRV record solution is fully supported there, in 2.1 it is experimental. VIPs are specifically recommended against by Couchbase these days. In older versions of the SDKs it was fine to do this and it helped with limiting the number of connections from the app to the DB nodes, but that is no longer necessary and can actually be a bad thing.
in addition to Kirk's long term answer (which I also advise you to follow), a shorter term solution may be to deactivate the 11210 bootstraping (carrier bootstrap) through the CouchbaseEnvironment by calling bootstrapCarrierEnabled(false) on the builder.
I don't guarantee that it'll work with a vIP even after that, but that may be worth a try if you're in a hurry.