Possible Issue with v3.5.0-beta1

[stuartofmt]

I have not used Dueui for a while as I was busy upgrading etc ...
I'm currently using R3.5.0-rc.3 in SBC mode.

Looking at the console log, I get the following error about 6 times per second from dueui-bundle.js:171. Dueui seems to respond,intermittently, with a delay. For example: home all seems to be ignored someties and not at other times. Is it stuck in a polling loop ?

Log:  
{timestamp: Wed Mar 13 2024 17:38:17 GMT-0600 (Mountain Daylight Time), severity: 'E', message: "Cannot read properties of null (reading 'value'): `${state.sensors.probes[0].value}`"}
message
: 
"Cannot read properties of null (reading 'value'): `${state.sensors.probes[0].value}`"
severity
: 
"E"
timestamp
: 
Wed Mar 13 2024 17:38:17 GMT-0600 (Mountain Daylight Time)
[[Prototype]]
: 
Object
constructor
: 
ƒ Date()
getDate
: 
ƒ getDate()
getDay
: 
ƒ getDay()
getFullYear
: 
ƒ getFullYear()
getHours
: 
ƒ getHours()
getMilliseconds
: 
ƒ getMilliseconds()
getMinutes
: 
ƒ getMinutes()
getMonth
: 
ƒ getMonth()
getSeconds
: 
ƒ getSeconds()
getTime
: 
ƒ getTime()
getTimezoneOffset
: 
ƒ getTimezoneOffset()
getUTCDate
: 
ƒ getUTCDate()
getUTCDay
: 
ƒ getUTCDay()
getUTCFullYear
: 
ƒ getUTCFullYear()
getUTCHours
: 
ƒ getUTCHours()
getUTCMilliseconds
: 
ƒ getUTCMilliseconds()
getUTCMinutes
: 
ƒ getUTCMinutes()
getUTCMonth
: 
ƒ getUTCMonth()
getUTCSeconds
: 
ƒ getUTCSeconds()
getYear
: 
ƒ getYear()
setDate
: 
ƒ setDate()
setFullYear
: 
ƒ setFullYear()
setHours
: 
ƒ setHours()
setMilliseconds
: 
ƒ setMilliseconds()
setMinutes
: 
ƒ setMinutes()
setMonth
: 
ƒ setMonth()
setSeconds
: 
ƒ setSeconds()
setTime
: 
ƒ setTime()
setUTCDate
: 
ƒ setUTCDate()
setUTCFullYear
: 
ƒ setUTCFullYear()
setUTCHours
: 
ƒ setUTCHours()
setUTCMilliseconds
: 
ƒ setUTCMilliseconds()
setUTCMinutes
: 
ƒ setUTCMinutes()
setUTCMonth
: 
ƒ setUTCMonth()
setUTCSeconds
: 
ƒ setUTCSeconds()
setYear
: 
ƒ setYear()
toDateString
: 
ƒ toDateString()
toGMTString
: 
ƒ toUTCString()
toISOString
: 
ƒ toISOString()
toJSON
: 
ƒ toJSON()
toLocaleDateString
: 
ƒ toLocaleDateString()
toLocaleString
: 
ƒ toLocaleString()
toLocaleTimeString
: 
ƒ toLocaleTimeString()
toString
: 
ƒ toString()
toTimeString
: 
ƒ toTimeString()
toUTCString
: 
ƒ toUTCString()
valueOf
: 
ƒ valueOf()
Symbol(Symbol.toPrimitive)
: 
ƒ [Symbol.toPrimitive]()
[[Prototype]]
: 
Object
[[Prototype]]
: 
Object
constructor
: 
ƒ Object()
hasOwnProperty
: 
ƒ hasOwnProperty()
isPrototypeOf
: 
ƒ isPrototypeOf()
propertyIsEnumerable
: 
ƒ propertyIsEnumerable()
toLocaleString
: 
ƒ toLocaleString()
toString
: 
ƒ toString()
valueOf
: 
ƒ valueOf()
__defineGetter__
: 
ƒ __defineGetter__()
__defineSetter__
: 
ƒ __defineSetter__()
__lookupGetter__
: 
ƒ __lookupGetter__()
__lookupSetter__
: 
ƒ __lookupSetter__()
__proto__
: 
(...)
get __proto__
: 
ƒ __proto__()
set __proto__
: 
ƒ __proto__()

My dueui config file configuration is:

configFileSettings = {
	duet_host: "192.168.30.30",
	duet_password: "reprap",
	duet_poll_interval_1: 2000,
	duet_debug_polling_enabled: 0,
	dueui_settings_dont_send_gcode: 0,
	dueui_test_mode: 0,
	duet_polling_enabled: 1,
	theme_name: "Darkly"
};

[stuartofmt]

@gtj0
An update. The error was caused by me changing my default probe number from 0 to 1 and not updating the dueui configuration.

Independently of that - its not clear why the error is being reported 6 times a second when the polling interval is set to 2000ms

[gtj0]

@stuartofmt I didn't see your first message, sorry about that. Not sure why. Glad you got it sorted. The reason you were seeing that message repeating as often as you did is because when you're in SBC mode, DueUI is connected to the SBC via a websocket and receiving streaming events. DueUI only goes into polling mode when it's connected directly to a Duet (Standalone mode).

[stuartofmt]

@gtj0
Ah HA! Good to know about the polling.

Is there a simple way to have some plain javascript executed as part of the config file? For example, I'd like to do something like this:

	If (Array.isArray(state.sensors.probes[0])) {
	    const myprobe = 0;
		}
	else if (Array.isArray(state.sensors.probes[0]))  {
		const myprobe = 1
		}
    else {
		const myprobe = "No Probe"
	}
	
	console.log("Probe Number is - " , myprobe)

and then later on use myprobe like this:

"field": "${state.sensors.probes[myprobe].value}"

[gtj0]

@stuartofmt You can indeed include javascript in the config file. It has a suffix of json to get around browser issues but it's actually parsed as a javascript file. In fact, you'll notice that the config is actually wrapped in a class named DueUIConfig. You can add a function to that class or just add it to the top level as a global function, then call it from a ${...} expression elsewhere in the config. In your example, you could create a a function called getProbeNum() that contains the code you posted modified to return the probe number, then call it like ...

"field": "${state.sensors.probes[getProbeNum()].value}"

I thought I had an example of this on the wiki but I don't see it now. I'll have to add it.

[stuartofmt]

@gtj0
Thanks, I'll give it a go.
As a side note, I have noticed that naming the config file xyz.js (instead of xyz.json) makes no difference. Or at least it seems to make no difference.

[gtj0]

@stuartofmt said in Possible Issue with v3.5.0-beta1:

As a side note, I have noticed that naming the config file xyz.js (instead of xyz.json) makes no difference. Or at least it seems to make no difference.

Now that I think of it, yeah. Originally, I was fetching the config using the old javascript Ajax calls which forbade retrieving code "for security reasons" and required the awful JSONP workarounds. When I did the big refactor a few years ago, I switched to dynamically updating the DOM with a "script" element which caused the browser to just retrieve the config file like any other javascript file. I forgot all about that until I just looked at the code.