Reboot button for wiser in the web app?

Has any one done this or know how to create a reboot wiser button in app that allows the user to restart the wiser with out being on site or having access to the systems page?

This would help a lot when the wiser "freezes"

 

Hi,

If the Wiser "freezes", how will it be able to respond to a button in the app?

Perhaps you could use a relay to switch the plug pack to the Wiser, then remotely switch the relay to force the Wiser to reboot. If the relay is controlled by C-Bus, you could use another device on the C-Bus (other than the Wiser) to remotely access and control it. If the relay is non-C-Bus, you could use whatever interface that non-C-Bus device supported (over Internet, phone, mobile phone, SMS, etc).

Another approach would be to determine why the Wiser is freezing and address that, so that it stops doing so. If the plug pack is in a hot environment, or more than a couple of years old, you may just need to replace the plug pack.

 

We experience Wiser lockups at quite a few sites we have them installed. I have worked with Clipsal technicians and no solution has been determined yet. Things that appear to help a small amount are the removal of the Wiser HD app, and reducing the amount on Logic used (not great as the Wiser is designed to support it). Looking forward to a solution from Clipsal.

 

This is the first time I'm hearing that removal of the Wiser HD app affects the stability of the Wiser. Is this with Wiser black or Wiser white? Do you mean that if you use Wiser HD on the iPhone/iPad, then the Wiser doesn't hang or fail immediately but eventually the Wiser hangs? And if you don't use Wiser HD, but instead use the older Wiser iPhone/iPad app, then it remains stable?

Now lets talk about Logic. Last week, Clipsal spent gobs of dosh flying an engineer out on site, only to find the following piece of logic deep inside the customer's project:
once RunTime mod 120 = 0 then
begin
CloseClientSocket(netp);
Delay(2);
OpenClientSocket(netp, netp_ip, 4001);
end;

Once GetLightingState(2)=ON then
begin
delay(0.5);
WriteClientSocket(netp, 'somestring'#13#10);
end;

What they were trying to do was have a lighting widget on the UI (GA 2) and then use that to control a 3rd party wifi connected network device (netp socket). But rather than use "if ClientSocketConnected()" or check for socket error when doing the tcp socket write, they were just closing/opening the socket every 2 minutes. The effect of this was that the end user was seeing random periods where they couldn't control their device since there were all kinds of scenarios which weren't being handled (eg: wifi device goes out of range, time wait due to socket close, interval of over 2 minutes during which connection isn't reestablished). The end result was the customer was given the impression that the Wiser was unstable when the reality was that the root cause was quite different. Writing the logic above properly would have saved everyone a tonne of time.

I can see how certain kinds of logic activity may affect Wiser stability. For example, if you are using logic for email/sockets/http/etc, there are conditions such as the name server not being present, that can cause the Wiser to spend too much time in that function and give the appearance of being stuck. If you've got a project with Logic where you can cause a Wiser to hang after some period, then please do post it here or send it to me. ([email protected]). I'll try it out on my setup and will let you know if I can reproduce the issue.

I just remembered something. djaggar had found a bug in Wiser a while back (2012) where more than 20k of logic would cause a problem. That was fixed a long time ago though in 1.24.0. That reminds me, what version of Wiser firmware are you running and which version of PICED are you using?

A detailed bug report really helps as the most effective way for Clipsal to fix a problem is once Clipsal can reproduce it.

 

If your wiser is freezing, then it is valuable to identify why that's happening. The first things I would check are that you've got up to date firmware (1.30.0), have loaded a compatible project using latest PICED (4.12.0). Typical debug steps would be:
- does the Wiser respond to pings?
- does the Adobe Flash UI work? if it does not, in what way does it fail? Any error messages?
- what does the Wiser's CNI status show? (you can access the CNI status from a browser by just going to http://cni's ip address/ , eg: http://192.168.2.2)

That said, if you just want to reboot an on-site Wiser unit, what you can do is go directly to its config page, eg: http://wiser.dyndns.org:8080/index_i.htm and click on save settings. That will automatically cause a reboot. This is assuming you've enabled remote access. If you've port forwarded the internal web server, then it would just be http://wiserip/index_i.htm. The index_i.htm part bypasses the Adobe Flash UI and takes you directly to the config pages.

 

what is the Wiser White edition?

Basically we have clients where everything will work fine, then at some stage (some sites only 3-4 days, some sites a fortnight) the Wiser is no longer accessible. Scenes/Schedules/Logic will not work. The UI background appears when logging in to the webpage but then an error shows (can't remember the exact wording but a stop sign is there) and no widgets are there. The only way to resolve it is to power cycle. Not sure whether we've been able to log directly into the setup page.

From memory, when the Wiser HD app is used, the time until the Wiser locking seemed to be shorter than when the standard Wiser app was used.

In our logic we are not using any email/sockets/http. Just simple cbus get/set and some time > < tests. The firmware would be the one before the latest release as i have been away for a little while. Just updated to the latest PICED yesterday.

Another Wiser related issue, I've noticed when i load the Wiser webpage UI, the number of widgets stated in the loading page is x2 +-2 of the actual widget number. EG if i have 90 widgets the loading screen says loading 182 widgets.

 

It is the replacement part for Wiser black described here: http://www.cbusforums.com/forums/showthread.php?t=11408

Ok. That info is a first step. What that suggests is that your browser is getting to the Wiser and the UI is coming up but stops due to an error. Which error it shows matters. For example, if it shows displays a stop sign and the dialog says transparent mode, then the root cause is that the unit has been switched into transparent mode. This can happen if there is something on the network that it trying to connect to the Wiser in toolkit/direct c-bus mode. If it shows "unable to connect to C-Bus", then that indicates that its C-Bus service is inaccessible, and we would then need to go down the path of figuring out what caused it to become inaccessible.

Here's what I would do when the problem occurs:
- access the Wiser from your browser
- take a snapshot of what it shows
- connect to the CNI webpage using the browser, take a snapshot of that. This will tell us whether the Wiser is still connected to the CNI and if the CNI is still connected to C-Bus

I'll ask whether the widget count issue is something Clipsal knows about.

 

When i got to a site the other day, this was the response when trying to log into the Wiser. It would ping without any issue.

Any word on the duplicate widgets?

 

Duplicate widgets are unexpected and indicate something is not right. I checked on a unit here with firmware 1.30.0 and 1.29.0 and PICED 4.12.0 and both indicate matching widget count when loading the UI, ie: widget count matches what I see in the widget manager in PICED. Could you let us know which version of PICED and which version of Wiser firmware you are using?

If it fails again, could you try to also go to http://wiserip/index_i.htm and take a snapshot. The index_i.htm part bypasses the Adobe Flash UI and takes you directly to the config pages and there is a Wiser tab which will show utilization.

 

Here are the details. Using PICED 4.12.0

(feel free to branch this into a new thread if you like)

I will keep you updated on the other issue

 

If possible, could you send us your project? You can send it through customer support or feel free to send it to me [email protected] . I'd like to load it on a unit and see what's going on. The widget count being 2x the actual count would suggest that the project has been corrupted.

 

Its not just one project. I have just checked more sites:
iPhone App - Web GUI
- 295 versus 581
- 132 versus 261
- 135 versus 270
- 97 versus 191

Some of these were uploaded directly from my laptop (while in local network), while others were uploaded from a PC on site.

I will send a project through to support

 

Email sent Wednesday morning. Are you able to confirm if it has been received? I have not received a reply yet.

 

Not sure if you mean you sent to me ( [email protected] ) and are waiting for a response or to customer support. I haven't received it yet.

 

I have sent it to CIS support

 

Thanks. I've received it. I loaded the project onto a unit and I see it saying 593 widgets when there are only 301 in the widget manager. I'll report back when I get some news on why this is the case.

 

There appears to be a little confusion over the counters in the Adobe Flash UI. The Flash UI counts instances of widgets required rather than the actual widget count.

Thus for a project with 20 widgets, with a location and function group for all then the count would be 40.

If you omit a location or function group for any widget then there would be one less in the count. Thus for a project with 301 widgets and 9 with no location, we would see 301x2=602-9=593.

Apologies for the confusion, and it IS different from the mobile apps which only count them once. We can look at changing this as it causes a lot of confusion, but thats the way it is for now....

I hope this at least clears up that concern