BASIC script MQTT publish working inconsistently

Hi,
I’m having some trouble with a BASIC script that has to publish some data via MQTT when those values change.
To do so I’ve based the script for the MQTT data exchange on the example displayed in the BASIC manual with a slight change in the MosquittoMQTTStatusChange function: I don’t have a ONTIMER that triggers the publish inside the function but I have a lot of ONCHANGE, each one for every value that I want to send, in the INIT section ouside any function.
When the script starts it doesn’t show any misbehavior: after the mqtt connects I can change the values and the get sent but after some times, maybe days, maybe hours or after turning the flexy ON and OFF, the script doesn’t work anymore: the values changes and thay don’t get sent anymore.
The mystake in my code that probably cause this is probably the ONCHANGE lines outside the function but I don’t understand why: in my line of thinking I put them outside so every time they changed the ONCHANGE would be triggered and start the publish. If I would have put them inside the MosquittoMQTTStatusChange function the ONCHANGE could be triggered only when the MQTTSTATUS changes to 5 (connected) so, if I understand how the BASIC works, during the normal/ideal conduct, when the connection to the MQTT broker doesn’t change status because the connection is stable, those ONCHANGE would never be triggered.
So, I tried to put the ONCHANGEs where the ONTIMER in the manual example is and is working right now. What I’m asking with this post is: can anyone explain me why those ONCHANGE have to stay inside the function? To me it doesn’t make sense and I’m afraid the problem is actually elsewhere and this is just working as a temporary patch.
I have included a copy of the BASIC script.program(3).bas (14.0 KB)
Thanks
Daniele

Bad news, putting the ONCHANGE inside the MosquittoMQTTStatusChange function doesn’t work anymore. I don’t know what to do.

WE currently use ONCHANGE To send MQTTT messages with no issues to Azure.

In the Init section we use the order of ONCHANGE then use a timer to wait 60 seconds before starting up the MQTT. Also use a few local tags to store connection status for use in other parts of the script.

// init section
ONTIMER 1,"@MQTTTryConnect()"
TSET 1,60

ONMQTT “@MqttReceiveMsg()”
ONMQTTSTATUS ‘@MqttCheckConn
END

FUNCTION MQTTTryConnect()
Print “MQTT Try Connect”
// check the MQTT status value if 0 then have not started mqtt
IF MQTT_CONNECTION_STATUS@ = 0 THEN
// if there is a valid cellular connection then set timer to start mqtt connection
b% = SIGNAL_NETWORK@
IF b% = 1 OR b% = 5 THEN
@MqttCONNECT()
ENDIF
ELSE
TSET 1,0
ENDIF
ENDFN

FUNCTION MqttCONNECT()
// MQTT connection parameter stuff here
Mqtt “Subscribe”, TopicToSubscribe$,1
Mqtt “Connect”
STATUS% = MQTT(“STATUS”)
MQTT_CONNECTION_STATUS@=STATUS%
//IF No error → Connected → Disable Retry timer
TSET 1,0
MQTT_CONNECTED@=1
ONMQTT “@MQTTReceiveMsg()”
ENDFN

1 Like

Hello pegu!

after turning the flexy ON and OFF, the script doesn’t work anymore:

if the Basic Script does not run anymore after a reboot you need to set it to autorun:

If you put ONxxx in the init section just means you set/configure this event directly at the Bootup phase.
If you set it in a function the first time this is set(configured) will be only the first time the function gets called… after that it will monitor that event anyway… but each time the function is called it will configure it again I think.

For the question why does it not publish anymore:
@tedsch Thank you for your Comments! I think you have some great tipps there!

My recommendation would go more into trying to visualize in the console or in the Eveltlogs were you are and if it can send it at that moment.

Using the print functionality:
PRINT “Debug description”
Or you could also log it into the Eventlog if you use:
(this is the normal Eventlog that gets stored even if the Ewon reboots)
image

since you are trying to debug the publishing part:
Maybe Print or log each time the publishing function gets called (and print with which variable) and what the Status is (you already check that)
Like this you can also keep an eye on how often this function is called. Originally the Timer is limited to max one Second. The ONCHANGE might happen too fast.

best regards
Franziska

1 Like

Hi,
thanks for the responses.
@tedsch Now I know that the ONCHANGE don’t have to stay inside the MqttStausChange function.

I already did that and the script is running when the ewon reboot but it just works differently compared to when you turn it off and on manually.

Ok, now I understand how the ONCHANGE works, I just need to call it once to say to the ewon to “watch out” for that variable to change.

Ok, I’ll try. I already put a lot of print, I’ll see if I can trace the erorr better with the LOGEVENT.

After some testing I observed something that can be useful to resolve the problem.
I saw that if the values that change come from the PLC they get sent, but when I try to simulate some values that have as I/O SERVER MEM( to change them manually) they are not sent.
It seems the ewon prefers the “real data” somehow. Also I have observed on the Event Logs of most stations that are not connected to the PLC right now the message id 26804 “stdios-Device ENTERS slow poll mode (S73&400 - Address IP: 192.168.10.10)”. Could that prevent the ONCHANGE to be triggered?
Thanks
pegu

Hi pegu!

Some Definitions on slow poll mode:
(You can find that in the IO Server Reference Guide)

ErrorRetry: Defines the number of errors before the device enters in slow poll mode. (Minimum 1)
SlowPollSkip: Defines the number of times the slave is skipped when in slow poll mode.
This delay depends on the poll rate.

If you have errors in the communication this might show an error for more than the Tag(s) that are actually in error because they are part of a Block of Data that has addresses next to each other and are polled in one go.

To find out which Tag exactly seems to not exist in the PLC anymore you can use the Option of ‘Disable Tag’s in Error’


Please make sure to definitely disable this after debugging again!
This is only for debugging and removes Tags that have an error from the list to be polled until there is a reboot or a fresh initialization of the IO Server.
If this setting is forgotten to be removed and a kable gets removed it will not poll any Data any longer…

Did you try changing the Memory Tags slowly (only once a second? or slower)
Did you see any other Tags changing at the same time?
You can also program in Basic the memory Tags to be written/changed for testing.

br
Franziska