Wob76

Members
  • Content Count

    194
  • Joined

  • Last visited

Posts posted by Wob76

  1. I didn't have to alter any docker configuration, and the web UI works fine.  Have you tried clearing browser cache, etc.

    Yeah, I also tried an alternative browser, it's odd, 2.0 without VPN (PIA) works fine, v1 with VPN (PIA) no problem, only change between them is the repository being pulled. Are those with it working use PIA or another VPN provider?

     

    I'll investigate further at some point but for now I'm happy with v1, might wait for the plugin support to be ported.

     

    Thanks for the help.

     

    Sent from my Pixel 3 XL using Tapatalk

     

     

     

  2. The web ui (not to be confused with the deluge thin client gui) works fine, if you cannot access the web ui then there is another issue in play (probably config related).
    I can't access the web UI with 2.0, but rolling back fixes it, did the configuration requirements change?

    Sent from my Pixel 3 XL using Tapatalk

  3. Indeed, but only in the case where there is a major issue, i.e. ip leakage, for now using the tags is the best way of switching back to v1.x.
     
    Just to be clear deluge v2.x DOES work, however you will need to update all plugins to v2.x compatible and make sure your deluge thin client is updated (if you use that). If you dont use the deluge thin client and you dont need third party plugins then you should be good - see post #3 in this thread for more details regards current limitations.
    Good to know, so does the web GUI fall into the 3rd party plugin category?

    Wob

    Sent from my Pixel 3 XL using Tapatalk

  4. So rolling back to binhex/arch-delugevpn:1.3.15_18_ge050905b2-1-04 fixes my issue, but it's not just the deluge port that isn't working, I can't connect to the web socket or the privoxy ports, logs are not giving me much indication of the issue.

     

    Wob

  5. When you say you try to access the web GUI, you launch the GUI from the docker tab? Can't see any errors out of the box from your log above, might be something in your run command

    I tried directly on the docket port for the web, I usually access via reverse proxy, neither work. With VPN on I don't see any activity in the deluge web log.  

     

     

    Here is the run command, but it hasn't been changed in months so I don't think it's the issue.

     

    docker run -d --name='delugevpn' --net='bridge' --log-opt max-size='50m' --log-opt max-file='3' --privileged=true -e TZ="Australia/Sydney" -e HOST_OS="Unraid" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='XXXX' -e 'VPN_PASS'='XXXX' -e 'VPN_PROV'='pia' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='yes' -e 'LAN_NETWORK'='192.168.0.0/24' -e 'NAME_SERVERS'='209.222.18.222,1.1.1.1,8.8.8.8,209.222.18.218,1.0.0.1,8.8.4.4' -e 'DEBUG'='false' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '8112:8112/tcp' -p '58846:58846/tcp' -p '58946:58946/tcp' -p '58946:58946/udp' -p '8118:8118/tcp' -v '/mnt/user/downloads/':'/data':'rw' -v '/mnt/user/downloads/':'/downloads':'rw' -v '/mnt/user/appdata/delugevpn':'/config':'rw' 'binhex/arch-delugevpn' 

     

    I'll also try the updated thin client tomorrow to see if the deluge port is open, but to me it seems like none of the ports are open while the VPN is up.

     

    Sent from my Pixel 3 XL using Tapatalk

     

     

     

     

     

     

     

  6. how are you attempting to connect to deluge?, if you are using the thin client from mac or windows then you wont be able to, as you will be using an out of date deluge client (v1.x) which does not connect to deluge v2.x.
     
    read post #3 of this thread for more details.
    I'm just trying to access the web GUI and I get nothing with the VPN on, I did try the windows app but it is probably outdated, I first noticed the issue as SickChill had an issue pushing a download to it. It was working find just a few days ago, but I can't work out if the issue is from the update or if it's a PIA issue.

    Sent from my Pixel 3 XL using Tapatalk

  7. As with a few others I seem to be having problems with PIA, It's been running fine since I moved from rutorrent around December last year, but stopped today after updating the docker yesterday. I have rolled back 2 versions and still can't get to the GUI and other dockers can't send torrents to it, I also tried a different PIA server to see if that was the issue without success. If I disable the VPN the GUI works.

     

    No sign of any issues within the logs that I can see.

     

    supervisord.log (VPN USER\PASS Masked)

    Created by...
    ___.   .__       .__
    \_ |__ |__| ____ |  |__   ____ ___  ___
     | __ \|  |/    \|  |  \_/ __ \\  \/  /
     | \_\ \  |   |  \   Y  \  ___/ >    <
     |___  /__|___|  /___|  /\___  >__/\_ \
         \/        \/     \/     \/      \/
       https://hub.docker.com/u/binhex/
    
    2019-07-16 11:53:31.684483 [info] System information Linux b50183129941 4.19.41-Unraid #1 SMP Wed May 8 14:23:25 PDT 2019 x86_64 GNU/Linux
    2019-07-16 11:53:31.739405 [info] PUID defined as '99'
    2019-07-16 11:53:31.778824 [info] PGID defined as '100'
    2019-07-16 11:53:31.880990 [info] UMASK defined as '000'
    2019-07-16 11:53:31.910583 [info] Permissions already set for volume mappings
    2019-07-16 11:53:31.944029 [info] DELUGE_DAEMON_LOG_LEVEL not defined,(via -e DELUGE_DAEMON_LOG_LEVEL), defaulting to 'info'
    2019-07-16 11:53:31.975033 [info] DELUGE_WEB_LOG_LEVEL not defined,(via -e DELUGE_WEB_LOG_LEVEL), defaulting to 'info'
    2019-07-16 11:53:32.005984 [info] VPN_ENABLED defined as 'yes'
    2019-07-16 11:53:32.044512 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn
    dos2unix: converting file /config/openvpn/openvpn.ovpn to Unix format...
    2019-07-16 11:53:32.090271 [info] VPN remote line defined as 'remote ca-toronto.privateinternetaccess.com 1198'
    2019-07-16 11:53:32.122070 [info] VPN_REMOTE defined as 'ca-toronto.privateinternetaccess.com'
    2019-07-16 11:53:32.154766 [info] VPN_PORT defined as '1198'
    2019-07-16 11:53:32.189617 [info] VPN_PROTOCOL defined as 'udp'
    2019-07-16 11:53:32.222186 [info] VPN_DEVICE_TYPE defined as 'tun0'
    2019-07-16 11:53:32.253393 [info] VPN_PROV defined as 'pia'
    2019-07-16 11:53:32.290793 [info] LAN_NETWORK defined as '192.168.0.0/24'
    2019-07-16 11:53:32.327020 [info] NAME_SERVERS defined as '209.222.18.222,1.1.1.1,8.8.8.8,209.222.18.218,1.0.0.1,8.8.4.4'
    2019-07-16 11:53:32.361452 [info] VPN_USER defined as 'XXXX'
    2019-07-16 11:53:32.394370 [info] VPN_PASS defined as 'XXXX'
    2019-07-16 11:53:32.426857 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
    2019-07-16 11:53:32.463078 [info] STRICT_PORT_FORWARD defined as 'yes'
    2019-07-16 11:53:32.496076 [info] ENABLE_PRIVOXY defined as 'yes'
    2019-07-16 11:53:32.530811 [info] Starting Supervisor...
    2019-07-16 11:53:32,723 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
    2019-07-16 11:53:32,723 INFO Set uid to user 0 succeeded
    2019-07-16 11:53:32,725 INFO supervisord started with pid 6
    2019-07-16 11:53:33,728 INFO spawned: 'start-script' with pid 147
    2019-07-16 11:53:33,729 INFO spawned: 'watchdog-script' with pid 148
    2019-07-16 11:53:33,730 INFO reaped unknown pid 7
    2019-07-16 11:53:33,736 DEBG 'start-script' stdout output:
    [info] VPN is enabled, beginning configuration of VPN
    
    2019-07-16 11:53:33,736 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
    2019-07-16 11:53:33,736 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
    2019-07-16 11:53:33,738 DEBG 'watchdog-script' stderr output:
    dos2unix: converting file /config/core.conf to Unix format...
    
    2019-07-16 11:53:33,789 DEBG 'start-script' stdout output:
    [info] Default route for container is 172.17.0.1
    
    2019-07-16 11:53:33,792 DEBG 'start-script' stdout output:
    [info] Adding 209.222.18.222 to /etc/resolv.conf
    
    2019-07-16 11:53:33,796 DEBG 'start-script' stdout output:
    [info] Adding 1.1.1.1 to /etc/resolv.conf
    
    2019-07-16 11:53:33,799 DEBG 'start-script' stdout output:
    [info] Adding 8.8.8.8 to /etc/resolv.conf
    
    2019-07-16 11:53:33,803 DEBG 'start-script' stdout output:
    [info] Adding 209.222.18.218 to /etc/resolv.conf
    
    2019-07-16 11:53:33,806 DEBG 'start-script' stdout output:
    [info] Adding 1.0.0.1 to /etc/resolv.conf
    
    2019-07-16 11:53:33,810 DEBG 'start-script' stdout output:
    [info] Adding 8.8.4.4 to /etc/resolv.conf
    
    2019-07-16 11:53:33,853 DEBG 'start-script' stdout output:
    [info] Docker network defined as    172.17.0.0/16
    
    2019-07-16 11:53:33,856 DEBG 'start-script' stdout output:
    [info] Adding 192.168.0.0/24 as route via docker eth0
    
    2019-07-16 11:53:33,858 DEBG 'start-script' stdout output:
    [info] ip route defined as follows...
    --------------------
    
    2019-07-16 11:53:33,858 DEBG 'start-script' stdout output:
    default via 172.17.0.1 dev eth0
    172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.4
    192.168.0.0/24 via 172.17.0.1 dev eth0
    
    2019-07-16 11:53:33,859 DEBG 'start-script' stdout output:
    --------------------
    
    2019-07-16 11:53:33,861 DEBG 'start-script' stdout output:
    iptable_mangle         16384  1
    ip_tables              24576  3 iptable_filter,iptable_nat,iptable_mangle
    
    2019-07-16 11:53:33,862 DEBG 'start-script' stdout output:
    [info] iptable_mangle support detected, adding fwmark for tables
    
    2019-07-16 11:53:33,898 DEBG 'start-script' stdout output:
    [info] iptables defined as follows...
    --------------------
    
    2019-07-16 11:53:33,899 DEBG 'start-script' stdout output:
    -P INPUT DROP
    -P FORWARD DROP
    -P OUTPUT DROP
    -A INPUT -i tun0 -j ACCEPT
    -A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
    -A INPUT -i eth0 -p udp -m udp --sport 1198 -j ACCEPT
    -A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
    -A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
    -A INPUT -s 192.168.0.0/24 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
    -A INPUT -s 192.168.0.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
    -A OUTPUT -o eth0 -p udp -m udp --dport 1198 -j ACCEPT
    -A OUTPUT -o eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
    -A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
    -A OUTPUT -d 192.168.0.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
    -A OUTPUT -s 172.17.0.0/16 -d 192.168.0.0/24 -o eth0 -p tcp -j ACCEPT
    -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
    -A OUTPUT -o lo -j ACCEPT
    -A OUTPUT -o tun0 -j ACCEPT
    
    2019-07-16 11:53:33,900 DEBG 'start-script' stdout output:
    --------------------
    
    2019-07-16 11:53:33,901 DEBG 'start-script' stdout output:
    [info] Starting OpenVPN...
    
    2019-07-16 11:53:33,908 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:33 2019 WARNING: file 'credentials.conf' is group or others accessible
    Tue Jul 16 11:53:33 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
    Tue Jul 16 11:53:33 2019 library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.10
    
    2019-07-16 11:53:33,909 DEBG 'start-script' stdout output:
    [info] OpenVPN started
    Tue Jul 16 11:53:33 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    
    2019-07-16 11:53:33,910 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:33 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.67.107:1198
    
    2019-07-16 11:53:33,910 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:33 2019 UDP link local: (not bound)
    Tue Jul 16 11:53:33 2019 UDP link remote: [AF_INET]172.98.67.107:1198
    
    2019-07-16 11:53:34,796 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:34 2019 [dfa7c579c79a374870350adc620b3760] Peer Connection Initiated with [AF_INET]172.98.67.107:1198
    
    2019-07-16 11:53:36,271 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:36 2019 TUN/TAP device tun0 opened
    Tue Jul 16 11:53:36 2019 /usr/bin/ip link set dev tun0 up mtu 1500
    
    2019-07-16 11:53:36,272 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:36 2019 /usr/bin/ip addr add dev tun0 local 10.22.10.14 peer 10.22.10.13
    
    2019-07-16 11:53:36,273 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:36 2019 /root/openvpnup.sh tun0 1500 1558 10.22.10.14 10.22.10.13 init
    
    2019-07-16 11:53:36,279 DEBG 'start-script' stdout output:
    Tue Jul 16 11:53:36 2019 Initialization Sequence Completed
    
    2019-07-16 11:53:36,394 DEBG 'start-script' stdout output:
    [info] Attempting to curl https://www.privateinternetaccess.com/vpninfo/servers?version=82...
    
    2019-07-16 11:53:38,815 DEBG 'start-script' stdout output:
    [info] Curl successful for https://www.privateinternetaccess.com/vpninfo/servers?version=82, response code 200
    
    2019-07-16 11:53:38,886 DEBG 'start-script' stdout output:
    [info] List of PIA endpoints that support port forwarding:-
    [info] ca-toronto.privateinternetaccess.com
    [info] ca-montreal.privateinternetaccess.com
    [info] ca-vancouver.privateinternetaccess.com
    [info] de-berlin.privateinternetaccess.com
    [info] de-frankfurt.privateinternetaccess.com
    
    2019-07-16 11:53:38,887 DEBG 'start-script' stdout output:
    [info] sweden.privateinternetaccess.com
    [info] swiss.privateinternetaccess.com
    [info] france.privateinternetaccess.com
    [info] czech.privateinternetaccess.com
    [info] spain.privateinternetaccess.com
    [info] ro.privateinternetaccess.com
    [info] israel.privateinternetaccess.com
    
    2019-07-16 11:53:38,891 DEBG 'start-script' stdout output:
    [info] Attempting to curl http://209.222.18.222:2000/?client_id=3dc3cde325c5b407199370458da9d041bb4d98e05d49cf6311983f2ac9112af7...
    
    2019-07-16 11:53:40,015 DEBG 'start-script' stdout output:
    [info] Curl successful for http://209.222.18.222:2000/?client_id=3dc3cde325c5b407199370458da9d041bb4d98e05d49cf6311983f2ac9112af7, response code 200
    
    2019-07-16 11:53:40,052 DEBG 'start-script' stdout output:
    [info] Checking we can resolve name 'www.google.com' to address...
    
    2019-07-16 11:53:40,272 DEBG 'start-script' stdout output:
    [info] DNS operational, we can resolve name 'www.google.com' to address '172.217.164.228'
    
    2019-07-16 11:53:40,273 DEBG 'start-script' stdout output:
    [info] Attempting to get external IP using Name Server 'ns1.google.com'...
    
    2019-07-16 11:53:40,961 DEBG 'start-script' stdout output:
    [info] Successfully retrieved external IP address 172.98.67.107
    
    2019-07-16 11:53:41,010 DEBG 'watchdog-script' stdout output:
    [info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 10.22.10.14 different, marking for reconfigure
    
    2019-07-16 11:53:41,014 DEBG 'watchdog-script' stdout output:
    [info] Deluge not running
    
    2019-07-16 11:53:41,017 DEBG 'watchdog-script' stdout output:
    [info] Deluge Web UI not running
    
    2019-07-16 11:53:41,020 DEBG 'watchdog-script' stdout output:
    [info] Privoxy not running
    
    2019-07-16 11:53:41,020 DEBG 'watchdog-script' stdout output:
    [info] Deluge incoming port 6890 and VPN incoming port 22783 different, marking for reconfigure
    
    2019-07-16 11:53:41,020 DEBG 'watchdog-script' stdout output:
    [info] Attempting to start Deluge...
    [info] Removing deluge pid file (if it exists)...
    
    2019-07-16 11:53:41,375 DEBG 'watchdog-script' stdout output:
    [info] Deluge key 'listen_interface' currently has a value of '10.2.11.6'
    [info] Deluge key 'listen_interface' will have a new value '10.22.10.14'
    [info] Writing changes to Deluge config file '/config/core.conf'...
    
    2019-07-16 11:53:41,586 DEBG 'watchdog-script' stdout output:
    [info] Deluge key 'outgoing_interface' currently has a value of 'tun0'
    [info] Deluge key 'outgoing_interface' will have a new value 'tun0'
    [info] Writing changes to Deluge config file '/config/core.conf'...
    
    2019-07-16 11:53:41,780 DEBG 'watchdog-script' stdout output:
    [info] Deluge key 'default_daemon' currently has a value of 'c11d5166a94dc914db6aea06fdfb28ed32903ef4'
    [info] Deluge key 'default_daemon' will have a new value 'c11d5166a94dc914db6aea06fdfb28ed32903ef4'
    [info] Writing changes to Deluge config file '/config/web.conf'...
    
    2019-07-16 11:53:42,105 DEBG 'watchdog-script' stdout output:
    [info] Deluge process started
    [info] Waiting for Deluge process to start listening on port 58846...
    
    2019-07-16 11:53:42,320 DEBG 'watchdog-script' stdout output:
    [info] Deluge process listening on port 58846
    
    2019-07-16 11:53:45,895 DEBG 'watchdog-script' stdout output:
    Setting "random_port" to: False
    Configuration value successfully updated.

    deluged.log

    11:47:53 [INFO    ][deluge.core.torrentmanager    :885 ] Finished loading 224 torrents in 0:00:00.325328
    11:47:54 [INFO    ][deluge.core.torrentmanager    :1609] on_alert_external_ip: 172.98.67.77
    11:47:56 [INFO    ][deluge.core.rpcserver         :171 ] Deluge Client connection made from: 127.0.0.1:46286
    11:47:56 [INFO    ][deluge.core.rpcserver         :197 ] Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost.
    

     

  8. 21 hours ago, dmacias said:

    Finally got around to  working on a new version using a different script I compiled for unRAID thanks to EmeraldPi

     

    https://github.com/taganaka/SpeedTest

     

    You can install this package using wget and installpkg from the command line


    https://github.com/dmacias72/unRAID-speedtest/raw/master/packages/SpeedTest-1.14-x86_64-1.txz

     

    Then run SpeedTest to test this script

    Nice, I just did a quick test and I seem to get speeds more aligned with my connection, are you planning on updating the plugin to use this?

     

    Thanks,

    Wob

  9. Hi, thanks for the plugin, I just installed this as I am having some issues with nodered startup, hoping a delay will help.

    I have 2 nodered containers,
    nodered
    nodered.dev

    I can only select the first of the two, I can select the rest OK, so seems it be the names are too similar, or the fact the icons are both the same?

    Thanks,
    Wob

    Sent from my SM-G935F using Tapatalk

  10. Just an update on my progress, It seems to be a stability issue with dzVents, with that disabled the docker is fairly stable (still crashed after a week), but as soon as I enable the scripts it will crash every few days.

     

    I have updated with each docker release, and currently at the version with Domoticz v3.8875, still crashing.

     

    The VM I am running is on v3.8834 and has been up for almost 13 days, so for the moment I am going to stick with a VM, seems more logical for my config as I have a few customisations I was having to do after each pull anyway, resources are higher, but not a deal breaker.

     

    Thanks for your efforts, I might revisit the docker again if future.

     

    Wob

  11. OK, I built up a VM with ubuntu server 16.04.3 and pulled down domoticz as per the install guide (https://www.domoticz.com/wiki/Linux) to ensure I wasn't messing anything up.

     

    After the install dzVents runtime is located in ~/domoticz/dzVents/runtime

     

    I did the same thing I was doing on a new pull of the container, created a dzvents script using the example code, this caused caused a segfault crash of the system. I found a thread that suggested going to Setup\Settings\Other and disabling both EventSystem and dzVents and then re-enabling them. This fixed the segfault.

     

    I then enabled the sample script, no crashing, created dummy hardware and a dummy switch, linking them, testing the switch and script and all behaved as expected.

     

    I could try the above on the container, but as you mention the dzvents runtime just doesn't exist, it seems it get cleaned from the old location, but not created in the new location. I can pull it seperate, but I want to ensure I am not introducing issues.

     

    I have now restored my database to see if it runs anymore stable than the container (at the moment it crashes every few days), I have just disabled any scripts that directly control anything, I have enough others running that dzVents it still active.

     

    I would like to stick to a container, as it uses less system resources, but stability is causing me issues, just trying to work out if this is due to the container, domoticz (maybe the beta) or I have a corruption in my database. Also considering going to a pi, now that my automation scripts are working nicely I need to keep it stable to keep the WAF and stop the lights, etc being manually turned off :).

     

    I would go back to a stable build, but I am using stuff in my scripting that requires dzVents 2.3 and that is not in stable, also much of the Xiaomi plugin requires beta and I have a heap of those sensors, hoping they get to another stable soon, but much of the bugs being reported seem to go without much response.

  12. Domoticz is a frustrating beast. On one had the development seems patchy and the forums are not very responsive to questions or issues. On the other hand it seems to be the easiest and most flexible open source home automation option, I have tried HASS, OpenHAB and a anything else I could find to run in a docker, and domoticz is still the best choice for me.

     

    I have told myself a couple of times that I would move to another system when I couldn't get help on the forum, but I have managed to fix the problem eventually. I am going to give a Smartthing hub a go soon, but I don't think it will have the scripting flexibility of domoticz, I have a number of things scripted depending on house occupancy, temps, etc. I don't think anyone has managed to get domoticz and smartthings to work together, but it would be nice to just use the scripting from domoticz and hand off the basic stuff to a hardware device.

  13. dzVents is definitely broken in the image.

     

    If I pull a fresh docker, and just create a test script, save using the demo code, which does nothing except make a log entry when a switch is pressed, the system becomes unstable, and continually restarts once every minute.

     

    I tried making a dummy switch and linking the script to that switch, but its still unstable. If I click said switch I see "Problem sending switch command" and trigger a restart.

     

    2018-01-22 11:07:31.636  EventSystem: reset all events...
    2018-01-22 11:07:31.636  EventSystem: Write file: /config/scripts/dzVents/generated_scripts/Test.lua
    2018-01-22 11:08:00.055  Domoticz V3.8805 (c)2012-2018 GizMoCuz
    2018-01-22 11:08:00.055  Build Hash: e160f7cc, Date: 2018-01-10 01:56:44
    2018-01-22 11:08:00.067  Startup Path: /var/lib/domoticz/
    2018-01-22 11:08:00.097  PluginSystem: Started, Python version '3.6.3'.
    2018-01-22 11:08:00.100  Active notification Subsystems: gcm, http (2/14)
    2018-01-22 11:08:00.101  WebServer(HTTP) started on address: :: with port 8080
    2018-01-22 11:08:00.104  WebServer(SSL) started on address: :: with port 1443
    2018-01-22 11:08:00.105  Proxymanager started.
    2018-01-22 11:08:00.106  Starting shared server on: :::6144
    2018-01-22 11:08:00.107  TCPServer: shared server started...
    2018-01-22 11:08:00.107  RxQueue: queue worker started...
    2018-01-22 11:08:02.108  EventSystem: reset all events...
    2018-01-22 11:08:02.109  EventSystem: Write file: /config/scripts/dzVents/generated_scripts/Test.lua
    2018-01-22 11:08:02.111  EventSystem: reset all device statuses...
    2018-01-22 11:08:02.131  Python EventSystem: Initalizing event module.
    2018-01-22 11:08:02.131  EventSystem: Started
    2018-01-22 11:08:02.132  EventSystem: Queue thread started...
    2018-01-22 11:08:02.579  PluginSystem: Entering work loop.
    2018-01-22 11:08:06.741  Incoming connection from: 192.168.0.250
    2018-01-22 11:08:11.207  EventSystem: reset all events...
    

     

  14. I have previously been using pipeworks to assign unique IP's to a few dockers, I thought I would move to the new inbuilt option, it works fine talking to the new docker from my network, but those dockers are not able to see the host, or any other dockers on the host.

     

    my subnet is 192.168.0.0/24 and I am just entering the ip like 192.168.0.245.

     

    Another question, is the MAC address that gets assigned to a docker in this fashion static, if I wanted to use DHCP?

     

    Am I missing something?

  15. I used 3.8805 and didn't see it. I haven't used any dzVents script though.
    But if you have pulled down dzvents from github into the config folder, this might be the reason you see the error. I find dzvents in /config/scripts/
    I did the pull after the error, to fix it, I may have messed something up in my database at some point.

    The scripts folder is the old location according to that thread.

    I'll pull a fresh image at some point and just install a single dzVents script, leaving my database out of it, and report back.

    Sent from my SM-G935F using Tapatalk

  16. Sorry, a rushed response while I was out and about as of 3.8551 dzVents is included according to this thread on the Domoticz forums.

    https://www.domoticz.com/forum/viewtopic.php?t=19738

    I noticed the error after importing my backup, maybe it only happens after enabling a dzVents script? Are you running any?

    My test build is also crashing, so I'll have to dig to find out what's causing it :( I'll do a fresh pull again and see if I can reproduce the error and when it happens.

    Sent from my SM-G935F using Tapatalk