Correct timezone offset setting.
Despite having UTC offset set to 0 in the PLC properties, and the time being set correctly in UTC:-
root@L203-sn218:~# date Mon 14 Jan 19:23:22 UTC 2019 root@L203-sn218:~# hwclock --localtime 2019-01-14 19:23:27.912454+0000
The result of "getlocaltime" in mervis is always 1 hour ahead.
Any ideas how to get it to use UTC time properly?
the change you have made is a change of the configuration of the PLC which has to be uploaded to take affect:
Please be aware of the network settings, which by default will change to IP of the PLC to the static 192.168.1.121
This seems to have worked - although when I did "download configuration" and the re-uploaded it, the timezone offset was still set to 0, it has applied it correctly this time.
Network interface setting reverted to "DHCP" from the previous static, but since I am using the Wifi interface, I commented out the reference to /etc/network/if-eth0.conf in /etc/network/interfaces.
The raspberry Pi seems to get really confused when wlan and eth0 are both configured for DHCP. When eth0 is disconnected, wlan0 interface stops working properly and everything slows to a crawl.
Only way I've seen to resolve it so far is to set eth0 to static and only use wlan0 with DHCP.
@robl The upload/download can be a bit confusing. The "Upload configuration" does set the PLC according to the settings in the solution. The "Download configuration" takes current settings stored in the PLC and copies them into the solution. Upload means "to the PLC", download means "from the PLC". In other automation software (Mitsubishi, Omron CX Programmer) is the meaning reversed.
Any computer which is connected to the same network via two interfaces gets confused. The "Network settings" in the Mervis only work with the wire ethernet. Support for setting the network of wireless ethernet is in the process.
Yeah, what I mean is, I first downloaded the configuration, saw that the setting was already 0, and then just uploaded it again. I didn't actually change anything in between. Anyway, seems to have now got it set correctly. Thanks for the help!
The multiple interfaces problem is odd, since the two interfaces are NOT both connected at the same time. eth0 was just set to DHCP and not connected, but the wlan0 interface only works properly when eth0 is plugged in. If eth0 is unplugged, the wlan interface works for a while but then eventually stops working properly.
This seems to be a Raspberry Pi issue people are reporting elsewhere, though not easy to debug as the unipi display port isn't accessible to connect, so it's hard to see exactly what's going wrong. (Maybe I will take the SD card and boot it in a regular Raspberry PI with a display connected, so I can better understand what is going on.)
The issue would seem to be a combination of the default ARP behaviour in Linux which responds with the wrong MAC address, DHCP, and that when there is no cable connected, in some situations Raspberry Pi still thinks it's up and tries to use eth0 anyway. (/etc/interfaces "auto eth0" vs. "allow-hotplug eth0")
So far, I have both interfaces set to dhcp, and I did have "auto eth0" in /etc/network/interfaces but looks like this was causing some of the problems, so I set it back to "allow-hotplug wlan0 eth0". and then set:
Now, when eth0 cable is removed, the interface still shows as "UP" but it deletes the routes and remove the IP config from the interface, and then because it responds to ARP with the correct MAC address for wlan0, it doesn't break.
Also set "wireless-power off" under the wlan0 interface config, but not sure if that made any difference. It would seem that some wireless APs are able to send a magic APSD request which causes the interface to go into power save mode. I don't think my AP does this.
I'll see how I get on. Worst case, I will have to just add commands to toggle eth0 down when wlan0 comes up, and toggle eth0 up again when wlan0 goes down, called from up / down hooks in /etc/network/interfaces.