Open Bikerjoy opened 8 months ago
{ "errors": [ "Socket closed with event 4429 Too many open connections on this server; count 2;" ] }
This is the out.log from MMM: [10.03.2024 10:43.31.183] [LOG] Reconnecting (retry no 7) [10.03.2024 10:43.31.184] [LOG] Initializing WebSocket [10.03.2024 10:43.31.505] [LOG] Tibber WebSocket closed [10.03.2024 10:43.41.190] [LOG] Reconnecting in 304 seconds
If I understand you correct, you say that the module is keeping the websocket open after the module (MM) is closed. How do you close MM? Can you examine and post the log from when closing?
The module is keeping the websocket open as long as it is running. The update frequency is decided by Tibber, as it is coming on a graphql subscription.
I have tried different methods of "closing". pm2 stop ... sudo reboot unplug power
The logs kind of just go quiet upon closure / reboot; [10.03.2024 11:10.20.552] [LOG] Reconnecting (retry no 3) [10.03.2024 11:10.20.554] [LOG] Initializing WebSocket [10.03.2024 11:10.20.975] [LOG] Tibber WebSocket closed
magicmirror@2.26.0 start DISPLAY="${DISPLAY:=:0}" ./node_modules/.bin/electron js/electron.js
magicmirror@2.26.0 start DISPLAY="${DISPLAY:=:0}" ./node_modules/.bin/electron js/electron.js
[10.03.2024 11:10.48.183] [LOG] Starting MagicMirror: v2.26.0 [10.03.2024 11:10.48.191] [LOG] Loading config ...
I realize this gets a little confusing, and I am not sure it is a fixable problem. It is clear that Tibber limits the amount of active sockets to one. It is just clear that MM seems to be more sensitive at start up (sometimes takes 15-20 minutes after reboot) than my pytibber display which starts up fine even with MM still running. It also seems that the available socket remains occupied long after powering off the MM.
{ module: 'MMM-Tibber', position: 'bottom_center', config: { tibberToken: 'XXX', homeId: 'YYY', is3phase: true, showCurrentGauge: true, showPowerGauge: true, showVoltageGauge: true, currentGaugeNominalValue: 25, currentGaugeMaxValue: 30, powerGaugeMaxValue: 17000, gaugesWidth: 345, gaugesHeight: 180, // Chart historyHours: 24, // How long history for price and consumption to see in the graph futureHours: 24, // How long into the future to see price data xAxisLineColor: "#333333", xAxisLabelColor: "#999999", adjustLeftMargin: 0, // Pixels to adjust margin adjustRightMargin: 0, adjustTopMargin: 0, graphWidth: 1200, // Uses available width by default graphHeight: 500, includeAdditionalCostsInPrice: false, // Price curve showPrice: true, dynamicMin: null, // Set graph min to a dynamic value. 0 = minPrice, ex. 0.2 = 0.2 below min price priceChartType: "column", // column, line or spline priceLineWidth: 3, // For line and spline, not column priceColor: "#cc0000", // For line and spline priceColumnColors: { // Only for column chart type NORMAL: ["#000055", "#0000dd", "#000088"], // Blue VERY_CHEAP: ["#004400", "#00dd00", "#008800"], // Lighter green CHEAP: ["#003300", "#00bb00", "#006600"], // Green EXPENSIVE: ["#440000", "#cc0000", "#770000"], // Red VERY_EXPENSIVE: ["#440000", "#aa0000", "#550000"], // Darker red UNKNOWN: ["#444444", "#444444", "#444444"] // Gray }
}
},
Hmm. Looks like I didn't come back to this one. Sorry. Is this still a problem, or have you found a solution?
I just configured a Magic Mirror with this very nice module.
I am running into issues with the MMM module were it does not release the websocket connection to tibber upon closure. I get connection refused in the API Explorer due to "too many connections" even if the Magic Mirror is shut down for quite some time.
I have developed my own display unit using the pytibber python library, and with this unit I have no problems running the API explorer at the same time and have never had any problem with too many connections.
There is a higher refresh rate (almost live, similar to the Mobile App) in the Magic Mirror whereas the pytibber implementation is on a 10s Callback by default. Could this be part of the problem?