TP-Link HS110

For issues with communication ports, protocols, etc.
Dinosaur
Posts: 1357
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: TP-Link HS110

Postby Dinosaur » Nov 27, 2019 1:55

Hi All

Expanded the system to 32 devices with the last 8 being Smart Switches (ie:HS200)
Turns out the important commands are identical to the Smart Plug.

Also incorporated a "Link" to the All ON /OFF button, so by enabling this link on any of the switches
you can manually turn this switch ON when you walk in the door and all the other enabled devices
will switch ON or OFF when you leave.(as long as you leave the BBB powered up)
A bit like a master circuit breaker.

I agree with some of the criticism on line that the switch looks like a rocker switch BUT it doesn't rock.
It's a weak spring return switch that is always in the same position.

Anyhow it works.

Regards
Dinosaur
Posts: 1357
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: TP-Link HS110

Postby Dinosaur » Jul 24, 2020 0:43

Hi All

Have expanded the system to use the Smart Switches as alarms. When movement is detected and the flood lights come on,
the smart switch for that zone is switched On. Once I register the addition , the location , the time and date are recorded in a log and an email sent to the duty volunteer to action.
All works great.

BUT,,,
Having an issue with the Beaglebone boot sequence that causes failures on initializing the PRUIO.
I have been ignoring it for months, but now that I want to reboot at midnight every day, it is becoming a problem.
If I put a delay of 40 sec's in, before starting my program it never fails, and all is good.
Now, nobody is concerned about a delay at midnight when the system is unattended, but occasionally the reboot fails.

Basically if I minimize the delay in starting my program(to a few sec's), the program will start until I get to the line indicated in the code below.

Code: Select all

Sub InitBBB
    If ErrControl.Errer = 0 Then ErrControl.Source = 700
    If Debug.PrintFlag = 4 Then Print ErrControl.Source;";";
    '----------------------------------------------------
    Dim as Long Xq
    WITH io
        'Configure O/P's to be pulled Low
        For Xq = 100 to 119
            IF .Gpio->config(IOCtrl.OPpinNbr(Xq) , PRUIO_GPIO_OUT0) THEN   'CREATES ERROR 39
                ErrControl.Errer = 1
            EndIf
        Next
        'P8_19 is the O/P's Init Bit (Hard Wired) and leave it Hi for Program to set Lo.
        IF .Gpio->config(IOCtrl.OPpinNbr(119), PRUIO_GPIO_OUT1) THEN
            ErrControl.Errer = 2
        EndIf
        IOCtrl.PortBit(120) = 1:IOCtrl.OldBit(120) = 1
        ' Now the Inputs pulled Hi (an actual I/P will pull it Low)'
        For Xq = 124 to 131
            IF .Gpio->config(IOCtrl.IPpinNbr(Xq), PRUIO_GPIO_IN_1) THEN
                ErrControl.Errer = 3
            EndIf
        Next
        IF .config() THEN ?"config failed (" & *.Errr & ")" : End 20
    End With
    If Debug.PrintFlag = 2 Then Print "Finished io"
    For Xq = 100 to 120
        IOCtrl.PortBit(Xq) = 0:IOCtrl.OldBit(Xq) = 1        'forces BBBController to turn it OFF
        BBBControl.InitOK = 1
    Next
    For Xq = 124 to 131
        IOCtrl.PortBit(Xq) = 0:IOCtrl.OldBit(Xq) = 0        'force Inputs to 0
    Next
    If Debug.PrintFlag = 2 Then Print "Finished IoCtrl"
End Sub

The program is started with a .service file that is dependent on "WantedBy=multi-user.target"
It is in a loop that whilst the error returned is > 0 the program will restart.
It seems impossible to find out which service is the last to be loaded so that it can be linked to that.
No amount of googling seems to shed light on that. Even the .idle option is automatically overruled after 5 sec's.
What does appear related is that the mouse is not available for at least 90 seconds after power On.
Have asked questions about this multiple times on the BBB forum, but not getting any answers.
But the program does not need the mouse for daily operation, unless I do some updating.
Tried disconnecting the mouse but it still seems to want to load the drivers and takes just as long.

So far I can only see a couple of solutions.
1: Find a way of starting the PRUI service earlier, but I don't know which other services it depends on.
2: Identify which is the last service started and then link to it. (I am amazed that in Debian there does not seem to be a way to list the order of boot)

Regards
TJF
Posts: 3601
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: TP-Link HS110

Postby TJF » Jul 24, 2020 6:57

Hi Dinosaur!

For me there're a couple of unanswered questions here:
  • What's the result of ?*io->Errr after the io=pruio() call?
  • What's the result of ?*io->Errr after the .Gpio->config(IOCtrl.OPpinNbr(Xq) , PRUIO_GPIO_OUT0) call?
Note: As long as you don't reset the error message (io->Errr = 0), you'll get the same error again and again. And, you shouldn't ignore the error messages. Most errors cannot get skipped, but should exit the program (see example sources).

1: Your custom service should not start before libpruio.service ist up ([Unit]After=libpruio.service).

2: Try command systemd-analyze plot > myboot.svg. It'll create a file named myboot.svg containing a picture of the timing from the last boot.

Regards
Dinosaur
Posts: 1357
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: TP-Link HS110

Postby Dinosaur » Jul 24, 2020 11:09

Hi All

TJF many thanks for your response.
In particular the plot command is something I have been looking for.

What's the result of ?*io->Errr after the io=pruio() call?

Cannot open /dev/uio5
What's the result of ?*io->Errr after the .Gpio->config(IOCtrl.OPpinNbr(Xq) , PRUIO_GPIO_OUT0) call?

Getting RTC info @;20:24:25
This was the correct time after my RTC was initialized. Note that this prints only once for a "For Next of 20" so the program bombs out on
the first instance of that error.

I did put After=libpruio-lkm.service and it is worth noting that that service is started after 22.5 sec and my program script starts at 24.5 sec.
The script first starts the xscreensaver then reads the RTC via 12c then sets the system time, so after about 3 sec's starts the main program.

What I don't understand is how the libpruio got the correct time 3 sec's before I set it.? (according to the myboot.svg)
I recall seeing a loading time of about 1.3.. sec's for libpruio-lkm, so that is still 2 sec's before I set it.(after a reboot it goes to November 2017 3 am)

It takes at least another 40 sec's before either libpruio-lkm is finished or some other dependant service is finished.
The program start is in a loop in the script (and I print the time) , so the first attempt was at 20:24:25, the final successful attempt was at 20:25:16.
Both errors repeat on each attempt to load the program.(8 attempts in total)

Regards
TJF
Posts: 3601
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: TP-Link HS110

Postby TJF » Jul 24, 2020 13:14

Dinosaur wrote:In particular the plot command is something I have been looking for.
systemd-analyse has further options for your task, it's worth to check them. The plot is the most easy to interpret.
Dinosaur wrote:
What's the result of ?*io->Errr after the io=pruio() call?

Cannot open /dev/uio5
What's the result of ?*io->Errr after the .Gpio->config(IOCtrl.OPpinNbr(Xq) , PRUIO_GPIO_OUT0) call?

Getting RTC info @;20:24:25
The first message means that libpruio cannot connect to the uio_pruss driver and consequently cannot operate at all. This error means that your program should call the DTOR and end (libpruio operations) immediately. (All errors from the CTOR should get handled that way.)

All further error messages are memory garbage from other processes. Ie. libpruio dosn't handle system time or RTC at all. Find all valid error messages in the docs in chapter Messages, and also some hints on how to fix them.

So please, stop ignoring the error messages!

Regards
Dinosaur
Posts: 1357
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: TP-Link HS110

Postby Dinosaur » Jul 25, 2020 8:45

Hi All

Once again many thanks for your responses.

So please, stop ignoring the error messages!
You are preaching to the converted. I may not handle them the way you are, but I have error trapping everywhere in my code. In the case of the error "Cannot open /dev/uio5" ,
that doesn't mean anything to me, so by numbering the error and trapping it on the return of the function allows me to follow it up.
Worth noting that I haven't had any errors since the installation, until I started tracking down a long boot time.

This boot time was about 1 min 45 seconds which was caused by a line in :/opt/scripts/boot/am335x_evm.sh that was converted to running in the background by converting a line:

Code: Select all

systemctl restart serial-getty@ttyGSO.service || true
to

Code: Select all

systemctl restart serial-getty@ttyGSO.service &
That gained 30 sec's in boot time. This also meant that the libprui-lkm.service was completed much earlier.
Together with other improvements that were high-lighted with the plot command, I now boot completely into the program in 1 min.
That still includes a 10 sec sleep for buffer in case other boards are slower.
The only other long delay is the "dev-mmcblkOP1.device" which I can improve by buying faster uSD, it takes a full 47 sec's.

Anyhow problem solved.

Regards
TJF
Posts: 3601
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: TP-Link HS110

Postby TJF » Jul 25, 2020 11:24

Dinosaur wrote:You are preaching to the converted. I may not handle them the way you are, but I have error trapping everywhere in my code. In the case of the error "Cannot open /dev/uio5" ,
that doesn't mean anything to me, so by numbering the error and trapping it on the return of the function allows me to follow it up.
Worth noting that I haven't had any errors since the installation, until I started tracking down a long boot time.
The converted is figthing against wind mills. As long as you do not even output (and know) the error message, there's no way to handle the issue in a proper way.

Anyway, you're adult and you should know what you're doing.

Good luck for your further development.

BTW:
I did already send a boot-log for an 18 s boot. You can compare it agianst your boot-log to identify optimization potential (please inform me when you find further optimizations). In that boot my custom controller is starting after approx 7.5 s. The further time is connecting to a WLAN and NTP time synchronization. The boot ends at multi-user-target, no Desktop on the BBB. Instead I run an http server (lighttpd) that provides a html-GUI for any browser (including password authentication). The GUI data is coming from an fcgi module (written in FB), connected to lighttpd.
Dinosaur
Posts: 1357
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: TP-Link HS110

Postby Dinosaur » Jul 25, 2020 21:30

Hi TJF

There is no way I could improve on 18 sec's, or come anywhere near it.
The uSD alone takes 45 + sec's, but i guess you are not running on a uSD.

I find the hardest part is researching what is needed and what is not.
Then testing the removals one at the time.

But as the application runs without any attention for months (but reboots each night) nobody really notices the long boot time.
For development it is a real pain, but 1 min is manageable. After exiting the program ,I have Openbox, Geany, Gede debugger and Xfe browser available.
Also found that hdmi is very flaky and does not handle different displays well.
In my office I use a large monitor, but on site a 7" lcd (on hdmi).
Finding that I can blit led's to the screen on my monitor (and they stay there) but on the 7" lcd I have to keep refreshing them.???
Lots of FBDEV(0) errors at boot that are dragging out the time as well,

Regards
TJF
Posts: 3601
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: TP-Link HS110

Postby TJF » Jul 26, 2020 10:21

Dinosaur wrote:There is no way I could improve on 18 sec's, or come anywhere near it.
The uSD alone takes 45 + sec's, but i guess you are not running on a uSD.
Booting from uSD. The eMMC boot sector is erased -> no access to eMMC.
Dinosaur wrote:I find the hardest part is researching what is needed and what is not.
Then testing the removals one at the time.
Sure, that's why I sent my boot-logs. You can see which services I identified as non-removals and check if you can drop all others. This saves a lot of time.
Dinosaur wrote:But as the application runs without any attention for months (but reboots each night) nobody really notices the long boot time.
For development it is a real pain, but 1 min is manageable. After exiting the program ,I have Openbox, Geany, Gede debugger and Xfe browser available.
GUI programs are safety risks. People can use this tools to manipulate the system.
Dinosaur wrote:Also found that hdmi is very flaky and does not handle different displays well.
In my office I use a large monitor, but on site a 7" lcd (on hdmi).
The hdmi auto-adaption to the monitor resolution doesn't work well. I prefer to set the resolution manually in uENV.txt:

cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet video=HDMI-A-1:800x480M@60e cape_universal=disable init=/lib/systemd/systemd
Dinosaur wrote:Finding that I can blit led's to the screen on my monitor (and they stay there) but on the 7" lcd I have to keep refreshing them.???
Lots of FBDEV(0) errors at boot that are dragging out the time as well,
What do you mean by "blit led's to the screen"?

Regards
Dinosaur
Posts: 1357
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: TP-Link HS110

Postby Dinosaur » Jul 26, 2020 11:59

Hi TJF

What do you mean by "blit led's to the screen"?
Yes that was bit vague wasn't it.
Allegro has a routine to "blit" an image to the screen.
The images I made are 20x20 square (of the background color) and then I "Blit" a round circle onto it which looks like an LED.
Some are coloured white for OFF and Yellow for an input.
Others are white for OFF and Red for an output ON.

The uSD that I use in my office works perfectly, but when I use the same uSD on site, the colored LED's somehow get erased and I have to
keep refreshing them so the operators can see which Smart Switches are active.
Perhaps it has something to do with the 7" display on-board memory, so I reduced all images to 16 bit color to try to reduce the load. To no avail.

I will keep at it, as the application is finished but there are so many things that I want to improve. Like I don't want any writing to the uSD.
That in itself appears impossible. Try stopping the Xorg.0.log from growing (or maybe you have).

I will have another look at your boot, but today realized that if I start timing the boot from the plot, systemd starts at 20 sec and my program loads at 48 seconds. Don't know if you are timing yours like that.

Regards

EDIT:
Deep in the bowels of the net I found this.
exec startx "$XDG_CONFIG_HOME"/Xorg/xinitrc -logverbose -1

Wiped the /var folder and let a reboot recreate it, then converted my line of calling the .xinitrc to .xinitrc -logverbose -1.
Problem solved, /var folder stays at same size after a number of reboots.

Return to “Hardware Interfaces / Communication”

Who is online

Users browsing this forum: No registered users and 1 guest