NodeLink0.6.10, ecobee3, and RPi1 problems

[larryllix]

I got it all installed and all seemed well for a day.

However, now I notice constant scraping problems with
"Ecobee Timer Error - Deserialization has failed [ecobee1]"

After a NodeLink reboot the data can take over 30 minutes to fill in, as it errors out at some point every scan.

Temperatures flip over to Fahrenheit, and then back at times. Some modes never update.
Controls all seem to work well and quickly enough.

It seems if I jog the seetings to "Hold" onthe stat app or webpage it updates but when I turn any Hold off again no update is seen in NodeLink.


Some other notes:
-It seems like the website and API may have changed/upgraded. Any possibility of making the Fan control work? It functions fine in the android app and website page controls.. Fan cycle time cannot be set over 55 minutes now.

- The three buttons in the admin console labelled "Home", "Away", "Sleep" are all permanent Hold modes and there is no ISY device page method to reset the modes back to "Schedule". These modes for programs have no settings = On/Off. UPDATE. Using the Set schedule= running turns off hold. All updates in NodeLink except the temperature never returns. I need to see the verbose comms for that digging that one.


I can give you access to examine/proof this if desired.

Thanks

[io_guy]

I can't follow anything you're saying here, there's a dozen things being described.  A log would be nice.

 

There's no API issue, I run an Ecobee.

[larryllix]

This is the same place it errors out after every reboot  of NodeLink.

 

After 5-15 minutes ModeLink  occasionally it gets more data. and sends it to ISY OK.

Controls, going out of ISY via NodeLink to the ecobee3, always seem to function fine, though.

2017-06-23 03:02:36 - ISY NodeLink Server v0.6.10 started
2017-06-23 03:02:38 - Web config server started (http://192.168.0.175:8090)
2017-06-23 03:02:38 - ISY resolved to 192.168.0.161
2017-06-23 03:02:39 - ISY Node Server config detected (profile 1)
2017-06-23 03:02:49 - Ecobee: New tokens received from ecobee.com [ecobee1]
2017-06-23 03:02:49 - Ecobee Data: {
  "thermostatCount": 1,
  "revisionList": [
    "311079071638:Gathering Room:true:170622213548:170621103120:170623030201:170623024500"
  ],
  "statusList": [
    "311079071638:compCool1,fan"
  ],
  "status": {
    "code": 0,
    "message": ""
  }
} [ecobee1]
2017-06-23 03:02:49 - Ecobee Timer Error - Deserialization has failed [ecobee1]

[larryllix]

OK. I discovered a lot more about this and have it running mostly.

 

I attempted to switch IP addresses of my better Venstar T7900 and my defective T7900 (headed to trash bin). My ASUS router would not let go of the old IP reservation in the router DHCP table. Even though the entry was gone and the router reset, the logs complained the MAC address was still reserving the same IP address as the replacement. The old Venstar was not even running and yet acted like the dup IP was clobbering data??? Forcing the old MAC address to new IP and power cycling the router fixed that problem.

 

NodeLink, finding a bad comm to the T7900 device, appeared to hang and confuse, the other device comms. I have noticed this previously with other node combinations. When one device has comm troubles on NodeLink, all the Ethernet comms, have more problems. In this case it mostly crippled the ecobee comms.

 

I don't think this was a data storm swamping (DoS) the port from the Venstar, but rather some driver data handling confusion. IMHO this seems more of a problem with the lower level multithread data sorting/handling in the RPi O/S.

 

You would know more about how much process isolation is needed by NodeLink, if any, as opposed to Raspbian, for the Ethernet port packet sorting.

 

 

Another factor is that the ecobee API seems incredibly slow. Full update of the Node takes about 5 minutes and simple mode changes on the ecobee stat take about the same 5 minutes, depending on synchro. It does appear to be push notification from the stat, as making changes on the stat appears to speed the general update response to ISY by pushing other data through.

 

Thanks for any of your time on looking into this.

[io_guy]

Nothing I can do, it's Ecobee's API. Their data only updates in the 5-15min range depending on the variable.

[larryllix]

Nothing I can do, it's Ecobee's API. Their data only updates in the 5-15min range depending on the variable.

Thanks. I figured that is was push from their end.

 

My deserialization problem still exists on every reboot, and until some update comes from the ecobee it sends all Farenheit temperatures. Sometimes it take 20-30 minutes after eboot before temperatures all switch to Celsius.

 

 

This strikes me as the C/F switch may be sent to NodeLink on the first send that breaks and then NodeLink assumes Fahrenheit. Are you using C or F?

[io_guy]

The deserialization error is causing your issue, unfortunately I can't reproduce.

 

I take the data you have above and run it through my system and it's fine.  If you have a Windows machine around try running it there and see if it happens.  No idea what OS/mono you're running.

[larryllix]

Thanks for the effort there!

 

UpDate: I did an update / upgrade on my RPi1 and the initialisation error happens at exactly the same place every time.

 

It seems the C/F switch must be included and missed in that package, leaving my temperatures all in Fahrenheit scale for an hour or two, before they change back to Celsius, as set in the ecobee3.

 

 

This afternoon I will try to set up my RPi 3 with NodeLink and see if that changes anything.

[io_guy]

Ditch the Pi1 and install the Pi3/mono based on my howto.  Your just spinning your wheels (and mine) with the 1 and old mono.

[larryllix]

Thanks io_guy

 

I installed on RPi 3 and all works well except NodeLink (and other packages) are hitting on the network port with a first request before the port is ready.

 

In  rc.local, inserted a delay that seemed to fix that

sleep 10 | mono /home/pi/node/NodeLink.exe

 

but later discovered

sudo raspi-config

has a "Wait for network on boot" option that is probably more appropriate globally

 

-------------------------------

Since the RPi would become basically useless for browsing (garbage) I would still like to fix or flick the thing so I re-imaged the OS but mono refuses to install on it now.

 

The OS is missing some command or function.

Any idea what the "illegal instruction" would be or how to fix the mono install?

pi@RPi1:~ $ sudo apt-get install mono-complete
Reading package lists... Done
Building dependency tree
Reading state information... Done
mono-complete is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
16 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libglib2.0-cil (2.12.43-0xamarin7+debian7b1) ...
Illegal instruction
W: removing assembly:  failed!
Illegal instruction
Use of uninitialized value $_ in scalar chomp at /usr/share/cli-common/runtimes.        d/mono line 275.
Use of uninitialized value $fullname in concatenation (.) or string at /usr/shar        e/cli-common/runtimes.d/mono line 225.
Illegal instruction

....continuation of many more mono setup errors

Thanks!

[io_guy]

No idea. Throw it in the garbage.

[larryllix]

OK I have some updates and a temporary solution after days of reinstalling and upgrading.

 

mono v5.0.1 has some RPi installation bugs that need to be fixed for Raspbian jessie running on  RPi1s. It will not install, despite many reboots, attempts, and reinstallations of the OS distro on a RPi1.

 

 mono v5.0.1 installation attempts throw "segmentation faults", and many "Illegal statements" from command lines that are not supported on th RPi1 OS version.  NodeLink will not run if a mono update to v5.0.1 (default and latest, at this time) is attempted.

 

To work around this I forced mono v3.12.0 (mostly v3.2.8 components) to install on my RPi 1, sucessfully.

 

With this mono version  NodeLink.exe installs and runs well with one caveat. It has problems with ecobee3 API upon power up only. Rebooting Nodelink after is successful almost immediately in every trial (about 5 times) I have done.

 

To install a version of mono older than the latest v5.0.1 this line in Automation Shack's instructions.

sudo echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list

 

can be modified to this line

sudo echo "deb http://download.mono-project.com/repo/debian wheezy 3.12.0" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list

 

NOTE:  The main option is replaced with a version 3.12.0 option.

 

I didn't try any  mono v4.X versions and it may be a better workaround, until they fix the v5.0.1 mono install.  mono installation didn't exibit any of these  problems on my RPi3  in the last  few days, running NodeLink 0.6.10

[io_guy]

Use the latest stable 4.X version then, not 3.X.

 

And again... move to your RPi3

[larryllix]

Too expensive to just throw out unnecessarily and with the above patch and mono v3.2.0, the RPi 1 works quite well  for now.

 

I'll wait until mono v5.x has a workable install for the Rpi 1 and maybe try again..

 

Thanks.

[io_guy]

Too expensive @$35 when an Insteon light switch is double that.

 

Fair enough, just stop asking for me to support it - my time is worth more.

[larryllix]

Too expensive @$35 when an Insteon light switch is double that.

 

Fair enough, just stop asking for me to support it - my time is worth more.

LOL

 

I just purchased another RPi at $112.99 but it needed a power supply and case and SD card  to work and needed to be shipped.

 

.Do you have an actual place to buy any RPi for $35?

[io_guy]

New Pi can use the same PS, SD and case.

$47 CAD https://www.buyapi.ca/product/raspberry-pi-3-model-b-armv8-with-1g-ram/

 

Topic locked.