MQTT.js | The MQTT client for Node.js and the browser | Runtime Evironment library

Is this an output that you want to achieve? In the below demo, I wrote a function that takes a high and low temperatures value and next is triggered on the button. The new data is attached to the chart via using the series.update feature.

Demo: https://jsfiddle.net/BlackLabel/he768cz3/

API: https://api.highcharts.com/class-reference/Highcharts.Series#update

I'll take a guess here. You are using a self signed certificate with your broker.

This will lead to the problem with any Web Browser because unlike when you make a HTTPS connection to the HTTP server with the self signed certificate the browser will not pop up a warning about an untrusted certificate that the user can choose to accept.

When Secure Websocket connections are made the certificate presented by the broker must already be trusted by the browser.

You have 2 options:

1. Add the CA certificate you are using to the brokers certificate store. How you do this will be different from broker to broker (and possibly also based on what OS the browser is running on). The problem with this that you have to do it to EVERY browser that ever wants to access the site. This is is only really an option in a development environment or a corporate settings where CA certs can be pushed by a central management system.

2. Use a certificate from a existing trusted CA. e.g. Letsencrypt.org these are free and already trusted by all browsers.

Connecting with keepalive: 0 tells the broker that he will never disconnect this client because of inactivity and there are no pings sent by the client at all.

Using keepalive: 20 e.g. (broker waits 1.5 * keepalive before disconnecting client) seems not to be the way to go here either since it requires you to prevent your client from sending pings to get disconnected and is clearly a doubtful misusage of the keepalive mechanism

I recommend to handle this on the client side exclusively by using a timer which fires after 30 s where mqtt.end() is called to cleanly disconnect your client and within the onMessage-callback the timer should get resetted

It seems like you're setting 1 lambda to handle 2 trigger sources, one is IoT service, the other is API Gateway Websocket. Since you use 1 lambda, you have to handle cases when the request is came from sources:

1. While event.requestContext is available when the request is triggered from API Gateway, it is not available when the request is triggered from IoT service (check the IoT event object here https://docs.aws.amazon.com/lambda/latest/dg/services-iotevents.html). So the error you faced (which is Cannot read property 'domainName' of undefined") is about that. You should turn off the lambda trigger from IoT service or handle the request when it comes from IoT Service.
2. I'm not sure about the forbidden error but it is more like you sent unstructured message to API gateway WS, it should be connection.send(JSON.stringify({ action: "sendmessage", data: "hello world" })); instead of connection.send("hello world");

Edited based on post update:

I know ws is there because if I console it it returns a big object with a bunch of functions

Lambda function is not really a server, it is an instance Node environment (that's why it is called FUNCTION), Lambda function doesn't work as the way you think normal Nodejs app does, its container (node environment) usually is halted (or freeze) whenever its job is done so you cannot keep its container alive like a normal server. That's the reason while you can console log the Websocket object, you cannot keep it alive, the NodeJS container was already halted whenever you return/response.

Since you cannot use the Websocket object to open WS connection in Lambda, Amazon offers a way to do that via API Gateway. The way we work with API Gateway Websocket is different than the normal server does too, it would be something like:

• User -> request to API Gateway to connect to websocket -> call Lambda 1 (onconnect function)
• User -> request to API Gateway to send message over Websocket -> call Lambda 2 (sendmessage function)
• User -> request to API Gateway to close connection -> call Lambda 3 (ondisconnect function)

3 settings above is configured in API Gateway (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-integrations.html), logic of 3 functions onconnect, sendmessage, ondisconnect can be handled in 1 lambda or 3 lambda functions depending on the way we design, I check your 3 lambda functions and it looks okay.

I see that you want to use IoT but I'm not sure why. You should test your Websocket API first without anything related to IoT. It would be better if you can tell what you want to achieve here since IoT works more like a publish/subscribe/messaging channel and I don't think it's necessary to use it here.

Ok it is working again, I needed to delete the device in amazon, and run the mos aws setup command again.

So the real problem was I was flashing my device each time I updated my code and it would overwrite my wifi settings, my aws settings and my mdash settings.

Thanks to help from a different source this solved it for me

There are 2 different things here.

1. Retained messages. This is a flag set on the message by the publisher, it tells the broker to hold on to the message and always deliver the last retained message on any given topic to a client when they first subscribe to that topic before any new messages are sent. The last retained message will always be replaced by the next message published on that topic that also has the retained flag set. You can read more about retained messages here

2. Queued messages. If the client subscribes to a topic at greater than QOS 0 then the broker will queue up messages sent for that client while it is offline. The client needs to reconnect using the same client ID and with the cleanSession flag set to false. You can read more about persistent sessions and queued messages here

Read the MQTT js docs carefully and read something about the actual MQTT messages too - ideally the standard itself or the nice interpretation at HiveMQ. The err callback parameter is for global failures, like transport layer errors. If the client sends a malformed topic name, or the client has insufficient permissions (this is exactly what HiveMQ mentions), you will find your failure as 0x80 code in the the granted array.

If the particular topic does not exist yet on the particular broker, that's not an error in MQTT. You may subscribe to wildcards, how the broker should handle that? Topic may start existing only when a first message is published to it.

The publisher and broker run in different containers, meaning they have different IPs.

When the publisher is trying to reach the broker at localhost:1883, it is normal to receive a ECONNREFUSED, hence the broker is not in the same container.

You should replace the 127.0.0.1 or localhost with the service name of the broker(broker in this case). The service name will be resolved to the correct IP of the broker container.