I have an APC Smart UPS 1500 connected via USB cable to a BeagleBone Green running NUT 2.8.1-5 on Linux 6.18.36-bone40. Even on earlier Linux kernels and versions of NUT, during some sort of UPS transition, I would start to get a log full of the these error messages:
usbhid-ups: nut_libusb_get_report: No such device (it may have been disconnected)
In detail:
kernel: musb-hdrc musb-hdrc.1: Babble kernel: usb 1-1: USB disconnect, device number 15 kernel: usb 1-1.4: USB disconnect, device number 16 kernel: usb 1-1: new high-speed USB device number 17 using musb-hdrc kernel: usb 1-1: New USB device found, idVendor=1a40, idProduct=0201, bcdDevice= 1.00 kernel: usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 kernel: usb 1-1: Product: USB 2.0 Hub [MTT] kernel: hub 1-1:1.0: USB hub found kernel: hub 1-1:1.0: 7 ports detected kernel: usb 1-1.4: new full-speed USB device number 18 using musb-hdrc kernel: usb 1-1.4: New USB device found, idVendor=051d, idProduct=0003, bcdDevice= 0.01 kernel: usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 1-1.4: Product: Smart-UPS_1500 FW:UPS 06.0 / ID=1028 kernel: usb 1-1.4: Manufacturer: American Power Conversion kernel: usb 1-1.4: SerialNumber: unique_number kernel: hid-generic 0003:051D:0003.0008: hiddev0,hidraw0: USB HID v1.11 Device [American Power Conversion Smart-UPS_1500 FW:UPS 06.0 / ID=1028] on usb-musb-hdrc.1-1.4/input0 usbhid-ups[31894]: nut_libusb_get_report: No such device (it may have been disconnected) usbhid-ups[31894]: nut_libusb_get_report: No such device (it may have been disconnected)
For some reason, USB devices 'disconnect' and reconnect. When the device reconnects, a new DeviceID is assigned to the USB device. This breaks the usbhid-ups drivers supplied by NUT the packages. That is, usbhid-ups no longer sees the APC USB device.
One forum article suggested that there is not enough power in the BeagleBone system to propery power a USB connection. The suggested solution is to add a powered USB hub. I gave that a try with no success in eliminating the problem.
To resolve this, I'm not sure if recent versions of the driver fix this, but I used Debian's udev system to sense the device id change and to restart the NUT USB driver.
In /home/debian, which is the default home directory, I created two files and ran 'chmod +x' on each to make them executable. When a USB 'ADD' state is detected, nut.target is restarted to initiate the detection and connection process. When a removal is detected, the service is stopped. The stop does not seem to be reliable, but the restart appears to be reliable enough to get things started again.
$ cat usb_add.sh #!/usr/bin/env bash logger "USB state change detected: $1 $2 $3" echo "$(date) USB state change detected: $1 $2 $3" >> /home/debian/usb-log.txt systemctl restart nut.target exit 0
$ cat usb_remove.sh #!/usr/bin/env bash logger "USB state change detected: $1 $2" echo "$(date) USB state change detected: $1 $2" >> /home/debian/usb-log.txt #systemctl stop nut.target exit 0
To determine useful attributes I used the following (the first is a shorter result than the second):
udevadm info --name=/dev/bus/usb/001/017 udevadm info --name=/dev/bus/usb/001/017 --attribute-walk
The rule which invokes these scripts is:
# cat /etc/udev/rules.d/89-usb-ups-change.rules
SUBSYSTEM=="usb", MODE="0660", ACTION=="add", ENV{ID_VENDOR_ID}=="051d", ENV{ID_MODEL_ID}=="0003", RUN+="/home/debian/usb_add.sh add '$env{DEVNAME}' '$env{ID_USB_SERIAL}'"
SUBSYSTEM=="usb", MODE="0660", ACTION=="remove", RUN+="/home/debian/usb_remove.sh remove $env{DEVNAME}"
These command variations were suggested to simulate a cable re-connect but did not reliably work. I resorted to physically disconnecting and reconnecting the cable to perform a proper test for tuning and production (using the major:minor usb device manufacturer code):
# major:minor usb device manufacturer code usbreset 051d:0003 # dev bus id udevadm test /dev/bus/usb/001/007
Each rule change test required the following to reload the udev rules:
udevadm control --reload-rules
To see what Nut sees:
# nut-scanner -U
Scanning USB bus.
[nutdev1]
driver = "apc_modbus"
port = "auto"
vendorid = "051D"
productid = "0003"
product = "Smart-UPS_1500 FW:UPS 06.0 / ID=1028"
serial = "unique id"
vendor = "American Power Conversion"
bus = "001"
device = "017"
busport = "002"
###NOTMATCHED-YET###bcdDevice = "0001"
A linux command provides a concise device and manufacturer id:
# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 016: ID 050d:0234 Belkin Components F5U234 USB 2.0 4-Port Hub Bus 001 Device 017: ID 051d:0003 American Power Conversion UPS
Other troubleshooting commands include:
udevadm monitorThis solution for those who might encounter Update 2.7.4 to 2.8.4 CP UPS driver disconnect (nut_libusb_get_report: No such device)
I've been hearing more and more about the SONiC Virtual Switch. It has come a long way since it's debut at an Open Compute conference some number of years ago.
To give it a try on non-ONIE hardware (nothing handy at the moment), this is what I did to get the .vs image working on my local Proxmox box:
gunzip sonic-vs.img.gz
qm disk import 116 sonic-vs.img local-btrfs --target-disk ide0
ssh admin@<ipaddr> -o PreferredAuthentications=password
Add additional instances to build infrastructure. Add interfaces to build a network.
I did some experimenting with drogon to port over a web site I had implemented in Wt webtoolkit web tool.
The views, controls, and static presentations performed well for building a web site in a traditional way.
However, when it came time to assign a domain name and run an SSL certificate based website, it started failing/crashing when certain SSL incompatible web queries were generated. It didn't have a recoverable failure mode. It simply raised an exception and crashed. I looked at the crash locations, and it seems that some clean up operations are mis-ordered, plus there were other problems. Then reading the issues list, the author even acknowledges that the whole SSL thing was a bolt-on after-thought and requires significant re-write.
Sigh. Drogon is out the window.
On to giving Boost Beast a try. This will require some work to add cookies and other refinements, but at least it is well integrated with SSL.
drogon is a fast C++ web framework.
Some build notes:
sudo apt install git cmake build-essential sudo apt install libjsoncpp-dev uuid-dev zlib1g-dev libsqlite3-dev \ libc-ares-dev dia libyaml-cpp-dev libssl-dev libbrotli-dev git clone https://github.com/drogonframework/drogon cd drogon git submodule update --init mkdir build cd build cmake .. make sudo make install
Create a project:
drogon_ctl create project project_name cd project_name/build cmake .. make cd .. # run project, default port is 5555 build/project_name
Fast and Accurate Anomaly Detection in Time Series - is this the cat's meow?
The fundamental challenge in real-world anomaly detection scenarios is related to the inherent class imbalance (anomalies are typically rare) and, for supervised methods, to the scarcity of labelled anomalous data. Indeed, labelling is both expensive and time-consuming. Conversely unsupervised methods do not require labelling, but may suffer from high false positive rates when deployed in safety-critical applications. In this work we introduce a novel unsupervised algorithm for anomaly detection in time series based on the Haar discrete wavelet and a suitably designed $t$-test. We establish the theoretical foundation of the proposed $t$-test and, through extensive experimentation across 343 datasets, demonstrate that our algorithm outperforms state-of-the-art unsupervised and self-supervised benchmarks.
I had someone Create an offline installation of SQL Server Management Studio for me. It was a fun install. Sarcasm intended. The installer could be so much smaller I think if it didn't have so many language packs in one bundle. Why not, if building an offline installer, why not allow a language selection right there.
The first step was to learn to start the installer from the command line with:
SSMS_22.2.1\vs_SSMS_22.2.1.exe --noWeb
At this point, it would unpack files and then silently quit. No messages at the command line.
The logs indicate an invalid certificate:
Certificate is invalid: C:\temp\SSMS_22.2.1\vs_installer.opc Error 0x80131509: Signature verification failed. Error: Unable to verify the integrity of the installation files: the certificate could not be verified.
Three of the certificates can be installed with:
certutil.exe -addstore -f "Root" "SSMS_22.2.1\certificates\manifestCounterSignRootCertificate.cer" certutil.exe -addstore -f "Root" "SSMS_22.2.1\certificates\manifestRootCertificate.cer.cer" certutil.exe -addstore -f "Root" "SSMS_22.2.1\certificates\vs_installer_opc.RootCertificate.cer"
By looking at the logs, there is a fourth certificate, but missing, so needs to be copied and installed in a similar manner from Microsoft Windows Code Signing PCA 2024.crt (github) or Microsoft Windows Code Signing PCA 2024.crt (microsoft.com)
The final hurdle has to Microsoft ODBC Driver installation. It installs Microsoft ODBC Driver 18 for SQL Server ok. But it fails while installing Microsoft OLEDB Driver 19 for SQL Server with a message along the lines of:
This application requires Microsoft Visual C++ Redistributable for Visual Studio 2022 (x64/x86, version 14.38 at minimum)
It fails even when installing Latest supported redistributable version x64.
The secret here is that the x86 version also has to be downloaded and installed. So you should have both installers:
VC_redist.x64.exe VC_redist.x86.exe
As a final note, the installer logs are in C:\Users\<UserName>\AppData\Local\Temp and are named dd_setup_yyyymmddhhmm_errors.log.
Install tool:
sudo apt install xclip
Perform the copy:
cat filename.base64 | xclip -rmlastnl -selection clipboard