Sunday, October 01, 2017

Openhab2 with telldus tellstick duo

The complete steps to get up and running with a raspberry3, openhab2 and telldus tellstick for managing lights.

  1. Install sdcard with image openhabian using win32 diskimager 
  2. Logon raspberry with openhabian:openhabian using putty
  3. Set new password with passwd
  4. Set static ip
    1. sudo nano /etc/dhcpcd.conf  (insert your own ip)
      interface eth0
      static ip_address=192.168.0.10/24
      static routers=192.168.0.1
      static domain_name_servers=192.168.0.1
  5. Update software
    1. sudo apt-get update 
    2. sudo apt-get upgrade
  6. Goto yourip:8080 , and choose standardpackage.
  7. Start a new sitemap.config  for example default.sitemap in /etc/openhab2/sitemapsEasiest way to open explorer and go to \openhab-confsitemap default1 label="Main menu" {
     Frame {
             Text label="Information" {
             Text item=Cpu_Load label="System load"              
           }
    Text label="Inställningar" icon="office" {
    Switch item=Scene5                                      
    }
     }
    }
    End example
  8. Telldus support
    1. Add to /etc/apt/sources.list
      deb
      http://download.telldus.com/debian/ stable main
    2. Add public key
      wget -q
      http://download.telldus.se/debian/telldus-public.key -O- | sudo apt-key add -
    3. Update repository
      sudo apt-get update
    4. Install telldus-core
      sudo apt-get install telldus-core
    5. Add devices in /etc/tellstick.conf  . Se example belowdevice {
                              id = 3
                              name = "Vardagsrum:rodlampa"
                              controller = 0
                              protocol = "arctech"
                              model="selflearning-switch"
                              parameters {
                              house="7778459"
                              unit="3"
                             }
                          }
  1. Train your devices with tdtool --learn 3 (where 3 is deviceID)
    Unplug nexadevice and run command, when system blinks its connected.
  2. Restart telldus services
    sudo /etc/init.d/telldusd restart - starta om telldus tjänster
  3. Install Tellstick bindings in paperUI
  4. Add all things that show up
  5. Create item from each things switchchannel and add to sitemap
  1. install bindings Weatherinfo for local temperatures and weather
    1. Install Eclipse IoT marketplace under Addons>bindings>misc
    2. Install weatherunderground
    3. Configure thing with location key (that you get att weatherunderground) and location. Works best with bigcitys like Sweden/Gotenburg
  2. To allow for js-scripts.
    1. Install JS transform
    2. Install RegEx Transformation
    3. Put scripts in /transform-folder
  3. To allow execs (running bash or commands like restart)
    1. Install exec-binding
  4. To get systeminfo stuff like cpuload
    1. Install binding SystemInfo
    2. Associate things with items
    3. Add items to sitemap
  5. To get sunstate
    1. Install Astro bindings
    2. Add things with your location as position.
    3. Create items that you link on sitemap
    4. Set category to good icons , like Moon
    5. To get phases to show, use formatting in label" [MAP(astro.map):%s]"
  6. To format dates in sitemap
    1. Show only hours, add to label [%1$tH:%1$tM]
      Example label="Soluppgång [%1$tH:%1$tM]"

Wednesday, September 27, 2017

Patching Sharepoint with the homebrew-method

Patchning Sharepoint is not something to taken lightly.
It's a high risk not to patch but a guaranteed risk to apply the patches.

Last year I had a difficult experience when I patched a semilarge(7 members) farm for the first time with Cumulative Updates-updates.
This had 5 webapplications and +200 databases. And it took some time. Like 30 hours, most of the time being lost when running psconfig on each host.
Supposedly, sharepoint should only upgrade the databases on the first member run, but something still takes a lot of time, even its only to check if upgrade is required.

So a more effective method was needed.
I looked into the impressive SPPatchify-project but found the results to be too inconsistent. Sometimes the script ran through it all said everything was green, when actually two servers had failed psconfigs and a lot of other issues giving half-finished state.
So I deviced my own hybrid method using the best parts of the sppatchify-idea and russmax exe-installationscript.

The method took the installationwindow down to 4 hours in total, where only 2 hours where complete downtime.
Its a bit more manual than others, but therefore also gives more control.

The steps
Preperations

  1. Take whole farm offline and take snapshots, or use regular backups. Whichever method you trust most.
  2. Backup All databases
Installation
  1. Stop all sharepointrelated-services
    1.  For AppServers 1. App-Prepatching
    2.  For Frontends  1. WFE-PrePatching
  2. Run exe on all members
  3. Start all services 
    1. For AppServers 2. App-PostPatching
    2. For frontends  2. WFE-PostPatching
  4. Export all databasinformation to file.
    1. ExportAllDbs.ps1
  5. Dismount all databases (after making sure you have all correct info on file from previousStep) This will take everything offline.
    1. DismountAllDbs.ps1
  6. Run psconfig on all members starting with AppServers
    1. RunPSConfig.ps1 on each member 
  7. Mount all databases
    1. MountAllDbs.ps1  - Update the filename to your exported databases
  8. Upgrade databases in parallel. While each db is upgrading website on it will be unavailable. If you're sql supports it you can mitigate this using -usesnapshot  How many concurrent jobs is depending on hardware. I found the sweetspot to be 4 concurrent jobs, after that it started taking longer time that running them in sequence. But this might vary. 
    1. UpgradeDatabasesFaster.ps1
  9. Check on warnings in Health Analyzer, make repairs if needed. 
  10. Make sure User Profile Synchronizer service is running (if your using FIM-sync)


Below all relevant scripts. Use at your own risk.



References:
https://blogs.msdn.microsoft.com/russmax/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install/ - Russmax excellent script for halting services before running exe. Saving hours
http://www.spjeff.com/2016/05/16/sppatchify-cu-patch-entire-farm-from-one-script/ - SpJeffs
https://blogs.technet.microsoft.com/stefan_gossner/2015/08/20/why-i-prefer-psconfigui-exe-over-psconfig-exe/ - Excellent resource for patching

Monday, March 20, 2017

Users break dispform

In this particular case a user decided to throw away the main webpart of the dispform.aspx. This caused all kinds of problems since it was a calenderlist.
In this situationen it wasn’t possible to create a new list since a lot of coded things worked with listids. Theres no versioning of dispform.
I first tried to use restore to sitedefinitions, but this kind of change didn’t qualify for making restore for some reason.
So this what came instead.

1. Find a functioning “vanilla” dispform.aspx from a list of same type
2. Open Sharepoint Designer, goto website of above list, find list and copy ListID
3. Find dispform of functioning list and export to file. Save locally on computer
4. Open locally saved dispform with notepad. Find and replace listid of sourcelist with targetlist listID (in calenderar two matches)
5. Opensharepint Designer, goto website of broken list.
6. All Files>Lists><mylist>
7. Take a backup of dispform with export to file, just in case you mess up.
8. Import locally modified dispform
9. Changes take effect immediatly.

References:
https://support.microsoft.com/en-hk/help/2000858/listview-webpart-required-on-dispform.aspx-page-for-document-library