Tips VMWare Workstation not compatible with Windows 10

Starting a VM this morning, I got a new message "VMware Workstation and Device/Credential Guard are not compatible". To be able to run my VM, I had to disable this Credential Guard.

Click to Read More

Credential Guard uses virtualization to store credentials in protected containers separate from the OS. As a result, the information Credential Guard protects is safe even if malware or some other malicious attack penetrates an organization's network.

But it prevents VMWare to run VM's.

To disable it, copy this script in a file named "disableCG.ps1" in your personal home folder C:\Users\<Your Name>\

Run next a PowerShell as Administrator:

Pay Attention that this will reboot automatically your PC !!

In this PowerShell, execute: cd ~

Next execute : .\disableCG.ps1 -Disable -AutoReboot

You will see errors displayed in Red in the PowerShell. This won't be a problem. And after a minute, the PC will reboot.

During the reboot, you will be prompted to confirm that you really want to disable the Windows Defender Credential Guard. Press the Windows Key or F3 to confirm.

 

Other options : https://windowsreport.com/disable-credential-guard-windows-10/

Ex. Execute in a PowerShell run as Administrator: bcdedit /set hypervisorlaunchtype off

 

I also had to remove "Guarded Host" and "Hyper -V" via the Control Panel > Programs > Turn Windows features on or off

But now, Docker does not run anymore on my PC as it needs Hyper-V :(

SmartHome Philips Hue lights Bulbs and Accessories become unreachable

Regularly, my Philips Hue lights and accessories do not respond anymore. Looking into the Philips Hue App, they appear as "Unreachable" (no link). The solution was to avoid WiFi interference!

Click to Read More

In French, the message displayed by the App, for the Lights and accessories, is "impossible d'établir le lien".

If your Philips Hue lights aren't responding, maybe it's time to ...

 

Notice that each time, a few bulbs and accessories were still connected and the App was perfectly able to connect onto the Bridge, both via Internet and via my local Network. Notice also that I have many Philips Hue Light Bulbs, Sensors and Dimmer Switches in the house (less than 50, which is the theoretical maximum for a Philips Hue Bridge) as well as a few Tradfri Bulbs in the corridors.

I really spent hours to investigate this issue which occurred once every few months ...

  • Unplug the power supply of the Philips Bridge for 30 sec.
  • Switch off all the lights for 30 sec.
  • Remove the Bulbs from their sockets.
  • Press the 4 buttons of the remotes (Philips Hue Dimmer Switch) all together for a few seconds (until the led start to blink red/green).
  • Press both the On and Off buttons of the remote to reset the Bulbs.
  • Turn on/off the lights quickly several times (and do an incantation for Apollo).
  • Delete and Re-add again the lights and accessories within the App.
  • Go through the whole FAQ of Philips Hue.
  • Drink a bottle of wine and cry alone in my sofa.
  • etc...

I was always finally switching off all electric devices which were possibly disrupting the Zigbee signals : my routers, my wifi access points, my other Bridges (Tahoma Somfy, Z-Wave, ...) ... and even powering off the whole house... This extreme action was solving the problem ! But impossible to conclude what was the precise root cause.

Today, the problem occurred again. After various unsuccessful attempts (those mentioned above),  I read on a blog that the quality of the ethernet connection between the Philips Hue Bridge and Internet matters ?!? And I realized that my Bridge was plugged into a Devolo Powerline Adapter (Ethernet via Power Sockets). I also remember that in the past, unplugging and replugging that Devolo Powerline Adapter was an action I did and which solved the problem (but I actually did this to restart the various Bridges and WiFi access points connected onto it).

So, I moved the Philips Hue devices from that Adapter into the main Ethernet Router and boom, it worked !

Et voilà ? Really not sure. The ethernet connection is only for the Bridge to have access on a Wifi Access Point and be able to connect with the mobile App... The bulbs and the Bridge are connected via Zigbee. So, there  must be another reason hidden behind this (fake) "solution".

Note that the Phillips Hue Light Bulbs, even though they are Zigbee, do not act as repeaters for anything except other Light Bulbs on the same Hue bridge if they are connected to the Hue bridge (They use actually a "Zigbee Light Link" protocol instead of the regular Zigbee).

As I noticed that the disconnected Bulbs are often the Tradfri ones and the Philips Hue far from the Bridge, I thought that the problem was possibly more with the Tradfri light bulbs not receiving/repeating properly the signal for the Philips Hue light bulbs ? Two possible options:

  • Replace the cheap Tradfri light bulbs with expensive Philips Hue light bulbs. I will do so soon or later...
  • Investigate why receiving/repeating the ZigBee signal could fail... I can start with this.

It's often mentioned on the web that ZigBee can suffer for WiFi interferences. It shares the same 2.4GHz wireless band as WiFi routers and overlaps by default with the Wifi channel 11 (https://statusq.org/archives/2018/01/09/8435/). And indeed, moving the Philips Hue Bridge or Turning On/Off all Wifi Devices in the house used to solve, at least temporarily, the problem.

Ex.: Zigbee channels 21 to 24 overlaps with WiFi channel 11 as illustrated bellow. 

A first obvious solution  is to disable the WiFi 2.4GHz band and use only the 5GHz band for the WiFi Devices at home. But not all of them support 5GHz...

Another solution is to change the channel used by the Philips Hue Bridge  to use a ZigBee channel having less conflict with your WiFi (All lights must be powered on). Do the change via Philips Hue App's settings > Hue Bridges > touch the "i" of the Bridge to update > ZibBee channel change > Change Channel.

It will take about 30 seconds, but the Hue system will change the channel to another one automatically. Once done, the lights should all come back online (And indeed, this did the trick once for me too, without doing any other action). If they don’t, turn them on and off again at the main light switch/plug socket. Possible Zigbee channels are 11, 15, 20 and 25

Philips Hue Zigbee channel

Also you can try to move the Philips Hue Bridge to another location, not too close of the WiFi access points and in central location regarding the various ZigBee devices. This is what I did by connecting the Bridge directly on the Router (So the solution was not the improvement of the ethernet connection quality, but most probably a lower WiFi interference next to that Router).

Notice that this won't update the channel used by the Tradfri lights! As explained on Reddit by Erik1971, you can try, after changing the Hue System channel, to power cycle the Tradfri lights (make sure they are not powered for at least 1 minute). This should trigger the Tradfri lights to scan over the channels to join the network again. Best way to do this is to power off all Tradfri lights and keep the Hue Lights and Bridge powered and then one by one power on the Tradfri lights (to prevent that the Tradfri Lights see the other Tradfri lights on the wrong channel and rejoin on the wrong channel).

So, for the time being, my conclusion is that bulbs and accessories became unreachable due to (many?) new devices connecting on the WiFi or WiFi Access Points changing automatically their channels (This can be checked with an App like Wifi Analyzer).

Synology Backup Synology to Unraid

The easiest way to backup a Synology NAS to Unraid Server is to use Hyper Backup on Synology and rsync on Unraid.

Click to Read More

First, enable rsync on your Unraid Server. It is preinstalled but not running as a daemon.

Create a file /boot/custom/etc/rsyncd.conf with the following content:

uid             = root
gid             = root
use chroot      = no
max connections = 4
pid file        = /var/run/rsyncd.pid
timeout         = 600

[backups]
    path = /mnt/user/backups
    comment = Backups
    read only = FALSE

Here above:

  • The name "backups" between brackets will be visible as "backup module" from the Synology. You can create several blocks like this one.
  • The "path" (here /mnt/user/backups) must exist on your Unraid server.
  • Notice: the folder /boot should exist. But you could possibly have to create the subfolders /custom/etc

 

Next, create a file /boot/custom/etc/rc.d/S20-init.rsyncd with the following content:

#!/bin/bash

if ! grep ^rsync /etc/inetd.conf > /dev/null ; then
cat <<-EOF >> /etc/inetd.conf
rsync   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/bin/rsync --daemon
EOF
read PID < /var/run/inetd.pid
kill -1 ${PID}
fi

cp /boot/custom/etc/rsyncd.conf /etc/rsyncd.conf

Finally, add the following line in the file /boot/config/go :

#!/bin/bash
bash /boot/custom/etc/rc.d/S20-init.rsyncd

 

Now, either reboot or execute: bash /boot/custom/etc/rc.d/S20-init.rsyncd

 

Go now on your Synology and open "Hyper Backup" to Create a new Data Backup Task:

Select rsync as Backup Destination:

And Create the backup Task with "rsync-compatible server" as Server Type:

Tips Use HDMI output of Lenovo ideapad Yoga 500 to get Dual Screen

When I connected for the first time my Lenovo Yoga on my TV, using a HDMI cable, I couldn't extend my Desktop to this second screen, using the F10 key. The solution was to do via the Intel Graphics Settings.

Click to Read More

  • Right Click on the Desktop to access its Display menu:

  • Click on the button "Detect":

  • Once the second screen has been detected, click either on "Clone Displays" or "Extended Desktop" and then Click "Yes" to apply the change:

 

Notice: I also had an issue with the HDMI port. I think this issue results from the pulling force exerted the each time one opens or closes it (the hdmi port is really next the lid). The "contacts" of the port are faulty (Loose contacts). As a solution, I had to push up the cable lightly up to force a good contact.

Synology GateOne not opening anymore on Synology as being "unsafe" due to an expired certificate.

There are many many reasons why sometimes GateOne does not open correctly on Synology. One of those is the expiration of your certificate.

Click to Read More

Notice that I am using my own packaging of GateOne for Synology (to be found here). In order to run properly, GateOne needs a copy of the certificates of your Synology. My Package is taking care of that during the installation. But if the system certificate expired or is renewed, GateOne will be in trouble as long as you don't copy yourself the renewed certificate into its setup folder. The symptoms are:

If you open GateOne in a DSM window, you get this: "The webpage at xxx might be temporarily down"

If you open GateOne in a new window, you get this: "Your Connection is not private", ERR_CERT_DATE_INVALID

If you click on Advanced, you see that "this server could not prove it is xxx : its security certificate expired xxx days ago":

If you click on "Proceed to xxx (unsafe)", GateOne will open in a new window. But if opened in the DSM, it will display the following messages:

To solve this, if you didn't renew your certificates yet, do it ! Go to the "Control Panel" > "Security" > "Certificate". Select your certificates one by one and open the "Add" menu + select "Renew certificate"

An alternative is to open a SSH console (See here) and execute the command: /usr/syno/sbin/syno-letsencrypt renew-all -vv

Once the certificates are renewed, in a SSH console, execute:

  • cp /usr/syno/etc/certificate/system/default/cert.pem /var/packages/MODS_GateOne/target/ssl/cert.pem
  • cp /usr/syno/etc/certificate/system/default/privkey.pem /var/packages/MODS_GateOne/target/ssl/privkey.pem
  • /usr/syno/bin/synopkg restart MODS_GateOne

Notice: the path "/var/packages/MODS_GateOne/target" is only valid for GateOne installed with my own package. The path of the official package is probably "/usr/local/gateone/ssl/".

Tips Cannot use inventory in Vivecraft

My daughter suddenly couldn't use the inventory anymore in Vivecraft, once opened. She couldn't pick or move items in there. The cause was that Vivecraft's window was not active on the PC at that moment.

Click to Read More

Vivecraft is a mod that turns Minecraft into an exceptional VR experience. Concretely, I use it to run the game from SteamVR and play with it using my HTC Vive pro setup (Be sure to setup and run the game as explained here. Launching the game from the VR Room or Steam does not work).

When my daughter experienced her issue with the inventory, I was working on the PC at the same time. Vivecraft works indeed fine if someone else is using the PC, as long as you don't need the mouse to interact with the game. And this is the case  when you want to use the inventory or use some menus.

Concretely, on the screenshot here under, the cursor + will only appear if, on the PC, the window of the game is activated. I.e.: if you clicked on it with the mouse or used Alt-Tab to give it the focus.

Vivecraft inventory

Vivecraft inventory

So, each time my daughter want to use the inventory, I temporarily give the focus to the window of ViveCraft by switching to it with Alt -Tab. I can next continue to work...

Et voilà.

SmartHome OpenHab: ServiceLocatorImpl has been shut down

I found a weird error by accident in the openhab.log of my Synology. It was due to the "Localisation" not configured properly in openHab's System.

Click to Read More

I found that error after stopping and starting manually openHab from a SSH console opened on my Synology to solve another issue.

To stop openHab installed on a Synology as explained here, via a SSH console run as root (as explained here), execute:

  • cd /var/packages/openHAB/target
  • ./runtime/bin/stop

To restart openHab later execute:

  • ./runtime/bin/start

NB.: if you execute this command soon after the stop, it won't work. You can simply re-execute the command a second time.

Here are more details about the error that I found in the log (located into \\<YourNas>\SmartHome\openHAB\userdata\logs\openhab.log)

javax.servlet.ServletException: javax.servlet.ServletException: A MultiException has 1 exceptions. They are:
1. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_2,3,718060201) has been shut down

at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:88) ~[bundleFile:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.Server.handle(Server.java:494) ~[bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]

This error appears because the location is not set in OpenHAB and your browser probably didn't have the permission to pass its own location to openhab.

The issue can be resolved by manually via the PaperUI > Configuration > System > Regional Settings.  There, define your language, your country/region, your Time Zone and your location (with a latitude and longitude - or - by moving the openHab pin onto your location).

SmartHome Troubleshoot Z-Wave Controller used by OpenHab

After reinstalling openHab on a new Synology, I had some 'Unknown' Z-Wave devices. The only way to et rid of them was to use "Z-Wave PC Controller" from  Silabs (previously named "Zensys tool").

Click to Read More

This is what was displayed in the Paper UI of openHab:

To solve this, I had two options:

The first option was to use the PaperUI's features of openHab to heal, reinitialize the device or remove the device.

The other option was to remove my Z-Wave Controller from my Synology, and plug in into a PC to clean it using Z-Wave PC Controller.

Use PaperUI's feature

Select your device via the PaperUI > Configurations > Things, click on the "Edit icon" (The pen in a blue disc) and scroll to click on the "Show More" link :

There, you have access to the various features :

Try those two actions:

  • "Heal the device" (See here) : it can be useful when the Z-Wave mesh is messed up and nodes become 'lost'.
  • "Reinitialise the device" : it does not hurt ;)

Wait next for a few minutes and refresh your PaperUI to check if the device is know fully recognized. 

Also check if there are any errors in the logs of openHab: events.log and openhab.log. If you installed openHab on your Synology as explained here, those logs are under the Shared Folder \\<YourNas>\SmartHome\openHAB\userdata\logs\

Install Z-Wave PC Controller

The download this software I had to find a "valid" Silabs account. Indeed, standard accounts have no access to the download section. Searching for "Silabs.com" on http://bugmenot.com, we find easily such "valid" account.

Once authenticated on Silbas.com, go to the Z-wave page here, and go to the "PC Programmer" section and click on Download Z-Wave Programmer

On the next page, click on the Download button in the upper-right corner (If it is not accessible anymore, find the msi in the attachement section of this post).

Unzip the archive and install the "PC Controller" (/bin/ZWaveControllerSetup.msi)

Clean-up your Z-Wave Controller

Now, plug your Z-Wave controller in your PC and open "PC Controller":

Click on the Gear icon in the upper-right corner to configure the software to use your Z-Wave Controller. You should see it in the pane "Serial Port Data Sources". Select it and click on "Ok" at the bottom-right:

Now, you have access to all the "data" (Z-Wave devices) configured previously on your controller. Here under, you can see that I have 13 nodes available:

To check which nodes are not yet available, Click on the top-left tail "Network Management". This will show you a list of all configured nodes. For each node, one by one, select it and press on "Is Failed". If the node cannot be accessed, it will be marked in red (See the nodes 23 and 24 here under). You can then remove it by clicking on "Remove Failed".

For each remaining node, you could click on "Node Info". This will collect more information than your controller did when it was connected on your Synology and managed by openHab.

You can add new devices easily, using the "Add" button. I did it for a Fibaro Heat Controller that I couldn't add via openHab.

You can test your Z-Wave Switches using "Basic Set ON" and "Basic Set OFF".

You can look at the topology of your mesh, using the tail "IMA Network" and by clicking on "Network Health".

Once you have cleaned-up your controller, you can re-plug it into your NAS.

Unplug/Re-plug a Z-Wave Controller on a Synology

When you remove and replug such a controller, it usually gets a new "terminal" (=a "new port"). A terminal is physically represented by a file named 'tty...' in the /dev folder and is the communication channel between the system (your Synology) and hardwares like the USB devices. By default, the terminal for the Z-Wave controller will be /dev/ttyACM0. But when you remove and replug it, it can get /dev/ttyACM1.

To check which terminal is used, open a SSH console on your NAS (as explained here) and type: ls -la /dev/ttyA*

You should get something like:
crwxrwxrwx 1 openhab dialout 166, 1 Dec 31 14:26 /dev/ttyACM0

If there are several terminals, unplug to Z-Wave controller, execute the command again and note the remaining names. Next, replug the controller, list again the terminals and compare the list with the one noted previously.

If the security of the terminal is not crwxrwxrwx, then (assuming the terminal is ttyACM0) execute: sudo chmod 777 /dev/ttyACM0

If the user is not openhab, then check first that it exists via the Control Panel of your DSM: Control Panel > User.

If it does not, you have not properly installed openHab on your Synology as explained here. The package is indeed configuring everything itself. If it exists, assuming the terminal is ttyACM0, execute: sudo chown openhab /dev/ttyACM0

If the group is not dialout, check that it exits via the Control Panel of your DSM: Control Panel > Group. Use "Edit Members" to check that the user "openhab" is in that group. NB.: a group "uucp" must also exist and contain the user "openhab".

If not, you didn't properly install openHab on your Synology as explained here. The package is indeed configuring everything itself. If it exists, assuming the terminal is ttyACM0, execute: sudo chgrp dialout /dev/ttyACM0

Finally, to check that the right terminal is used by openHab to communicated with the Z-Wave Controller, go to its configuration via that PaperUI > Configuration > Things. Select your Z-Wave Controller and Edit it. In the "Port Configuration" part, you should see that the "Serial Port" is the terminal you found with the command ls -la /dev/ttyA*.