I’m migrating from ST to HE and have a number of pistons which perform a get on a local ip address on the same network as the hub. These work fine on ST WC.
The get is performed on an IP e.g “Make a GET request to [192.168.0.7];”
The same pistons on HE fails to return $response, and I suspect is not even managing to make the call out.
I’ve confirmed the HE hub can ping the address. The following error is returned in the HE logs
app:682022-08-26 12:20:00.991 am debugReleased Lock and exiting
app:682022-08-26 12:20:00.988 am debugExiting
app:682022-08-26 12:20:00.945 am info ║║ $response=*
app:682022-08-26 12:20:00.878 am errorhttp Response Status: 408 error Message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The piston log contains the following
26/08/2022, 00:20:00 +901ms
+2ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 24ms, canQueue: false, calledMyself: true
+6ms ║RunTime initialize > 5 LockT > 0ms > r9T > 2ms > pistonT > 1ms (first state access 3 3 2)
+8ms ║Runtime (6449 bytes) initialized in 2ms (v0.3.114.20220822_HE)
+26ms ║╔Execution stage started
+34ms ║║Executed virtual command setVariable (1ms)
+38ms ║║Calculating (string)$response= + (string) >> (string)$response=
+39ms ║║Calculating (string)$response= + (string)* >> (string)$response=*
+42ms ║║$response=*
+44ms ║║Executed virtual command log (3ms)
+48ms ║║Comparison (dynamic) null is_not (string) [:] = true (1ms)
+49ms ║║Condition #6 evaluated true (3ms)
+50ms ║║Condition group #5 evaluated true (condition did not change) (5ms)
+55ms ║║Skipped execution of physical command [Start NAS-314].on([]) because it would make no change to the device. (2ms)
+56ms ║║Executed [Start NAS-314].on (2ms)
+61ms ║║Executed virtual command [Start NAS-314].setVariable (1ms)
+65ms ║╚Execution stage complete. (39ms)
+68ms ╚Event processed successfully (66ms)
26/08/2022, 00:20:00 +877ms
+3ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 0ms, canQueue: true, calledMyself: false
+5ms ╚Event queued (3ms)
26/08/2022, 00:20:00 +803ms
+4ms ╔Received event [Home].execute = :7bc150e5a57d1ea8be13be7db6ab459b: with a delay of 15ms, canQueue: true, calledMyself: false
+13ms ║RunTime initialize > 12 LockT > 1ms > r9T > 2ms > pistonT > 1ms (first state access 9 5 7)
+16ms ║Runtime (6440 bytes) initialized in 2ms (v0.3.114.20220822_HE)
+18ms ║╔Execution stage started
+26ms ║║Sending asynchttpGet web request to: 192.168.0.7
+28ms ║║Executed virtual command httpRequest (3ms)
+31ms ║║Requesting wake up at Fri, Aug 26 2022 @ 12:20:24 AM BST (in 23999ms) for 1 (st:2)
+38ms ║╚Execution stage complete. (21ms)
+64ms ║Setting up scheduled job for Fri, Aug 26 2022 @ 12:20:24 AM BST (in 24018ms)
+66ms ╚Event processed successfully (63ms)
Clear Full
app:682022-08-27 08:55:00.958 am info ║║ $response=*
app:682022-08-27 08:55:00.898 am errorhttp Response Status: 408 error Message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Not sure if it helps, but there’s a slightly different error when calling an IIS server on a windows PC (see below) the above error is from a linux os app:702022-08-27 08:53:54.899 am errorhttp Response Status: 408 error Message: Remote host closed connection during handshake
What code produces this message?
There is a ignoreSSLIssues parameter for http calls, if set to true the call should accept all sorts of bad, self-signed, expired, etc. certificates.
A little further info, If I use a an external url to my router, and set up port forwarding on the router, the request is successful using (e.g) http://mydyndnsaddress.co.uk:1234
What that says is that webCoRE is doing it's job, i.e. sending the payload to where you tell it; the issue appears to be in how you are addressing the server - might want to take a look at the route and authorizations the port forward takes to it and see if you can match it inside the piston.
I’m not sure why it doesn’t work. The same pistons work fine on ST, although the way that works could be very different, as the get is executed on the ST hub, while the code runs in the cloud.
A few other points I’ve noticed,
Different errors are returned by different local targets. A windows 11 IIS closes the connection. so that would indicate routing is correct.
A wake on LAN piston which addresses the same devices works.
The HE nodeRed application connects to a rasp PI, but the get request to the same PI from webcore to a node.js target fails.
I could get the pistons to work by setting up more port forwarding rules and using my DDNS url, but I don’t really want to give external access, particularly to the NAS devices. It would also be a shame to have to ‘go external’ when one of the benefits of webcore on nubitat is that its all a local system.
you may need to post full logs and the current piston so folks can see all the data.
webcore does not try to re-write addresses, ie if you give it local it will use local. Are you using a name or an IP address? You might try to not have dns lookups involved. DNS is as HE provides it, webcore has no control on this.