I definitely do not recommend 3.0 snapshots to anybody who is not testing to report issues on GitHub. I am sure it is no where near stable or usable for daily use. I believe there are also 2.5 snapshots focused on fixing bugs in 2.5.
Thought about option #2 which is why I tried adding one new device.
Have not ventured in removing more device from Alexa to try rediscovery.
Tried log level TRACE but speed reading is not my gift.
I did mention adventurous and made it bold.
Also the last update on frog for 2.5 was in April. Jenkins does not want to open at the moment but will check the latest version there as well.
Remove the DEBUG from Insteon so only log is TRACE from Hue.
Thoughts on option 1 ?
Also, still would like to see /var/lib/openhab2/config/org/openhab/addons.config
log:set TRACE org.openhab.binding.hueemulationservice
For some reason I am not getting any TRACE from Hue Emulation.
I am seeing TRACE from insteonplm and it is showing the wrong device being called to turn on. Asked for LIGHT B and LIGHT A is being turned on.
2019-12-29 13:51:32.625 [INFO ] [g.insteonplm.InsteonPLMActiveBinding] - Item: LIGHT_A got command ON
2019-12-29 13:51:32.628 [DEBUG] [eonplm.internal.device.InsteonDevice] - processing command ON features: 5
2019-12-29 13:51:32.631 [TRACE] [eonplm.internal.device.DeviceFeature] - GenericSwitch uses LightOnOffCommandHandler to handle command OnOffType for xx.xx.xx
2019-12-29 13:51:32.637 [INFO ] [onplm.internal.device.CommandHandler] - LightOnOffCommandHandler: sent msg to switch xx.xx.xx to on
2019-12-29 13:51:32.640 [INFO ] [onplm.internal.device.CommandHandler] - Sending message to xx.xx.xx
2019-12-29 13:51:32.643 [TRACE] [eonplm.internal.device.InsteonDevice] - enqueing direct message with delay 0
2019-12-29 13:51:32.646 [TRACE] [.internal.device.RequestQueueManager] - scheduling request for device xx.xx.xx in -3 msec
:org.apache.felix.configadmin.revision:=L"3"
binding="mqtt,astro,insteonplm1"
legacy=B"true"
misc=",hueemulation,mqttbroker"
package="standard"
persistence=",mqtt"
remote=B"true"
service.pid="org.openhab.addons"
ui="basic,paper,habpanel,homebuilder"
Definitely don’t need bleeding edge. I have enough cuts and bruises as it is.
Ok, now uninstall insteonplm, stop OH, clean cache and restart. After OH is up and running place the jar file below (click on link) in usr/share/openhab2/addons and restart OH.
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.insteonplm/1.14.0-SNAPSHOT/
Actually, after you have cleaned the cache you can place the jar file while OH is stopped and save sometime on another restart.
> 2019-12-29 14:38:20.119 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.insteonplm-1.14.0-SNAPSHOT.jar > org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.insteonplm [203]
Try OH restart a few times and if that does not work go to console and try to resolve the bundle 203. BTW I usually do not have luck with console resolve but worth a shot as its a 1.x binding.
Console commands if you need em.
203 │ Installed │ 80 │ 1.14.0.201912122158 │ openHAB Insteon PLM Binding
It should mention it’s active.
Run bundle:list and see if it show’s as active. Did you use the console after or before restarting OH?
Needed to install gnu.io Yet its still turning on the wrong lights.
This seems like a Alexa or Hue issues at this point. I guess.
Tempted to delete devices from Alexa and add them again but am afraid she will not find them.
A side question: can openhabian backup img use pishrink? If so how to you restore the image to a sd for booting on the pi?
Openhabian runs on raspian lite if you installed the image so it’s like any other debian based OS. Short answer is yes you should be able to use pishrink.
MAKING PI BACKUP CLONE IMAGE:
sudo fdisk -l (find the name of disk with image)
sudo dd if=/dev/sdb of=~/raspbian_backup.img (disk is /dev/sdb
and ~/raspbian_backup.img is my home directory and name of image.)
TO COMPRESS IMAGE:
sudo ./pishrink.sh ./raspbian_backup.img
RESTORE IMAGE:
Unmount all directories of sd card
sudo umount /dev/sdb1 /dev/sdb2 /dev/sdb3 /dev/sdb4
INSTALL IMAGE:
sudo dd if=~/raspbian_backup.img of=/dev/sdb
Not sure about your current config but if your wanting to put OH on an SD card to test with the setup you have now the openhab-cli backup --full should be all you need. Just install a fresh image to the card and after OH is up and running (45 min or so) then restore your configs.
To restore the backup from openhab-cli:
Place the backup zip file into the backups folder
then,
sudo systemctl stop openhab2
openhab-cli restore /path/to/zipped/backup (var/lib/openhab2/backups)
sudo systemctl start openhab2
but I would stop openHAB first.
1 Like
Yes, as @Bruce_Osborne mentioned stop OH first.
Thanks Bruce
Guess I shouldn’t have used the word “should” as you can use pishrink. Those are my note to self from a few years ago.
on Friday I dd my openhab microSD to a folder on my notebook creating openhab_bk.img 31G size file.
Can I pishrink that and then install on blank microSD or am I stuck dd the entire 31G?
Would like to get things back to where they were before things went bad this morning. Then try to figure out why things went wrong this morning.
You didn’t make a backup before upgrading? … Never mind, just read over the first line again.
I honestly do not know as it’s been a long while since I used dd, any advice @Bruce_Osborne? What I do know about dd it’s powerfull and if not done correctly can make for a really bad day/week.
I really don’t think you need pishrink to get OH on SD card. See my post again as I have edited it to include restoring from openhab-cli backup. Hence the reason I have not used dd in some time.
I cloned the the entire microSD on Friday. I was under the impression the pishrink would remove the nothing space on the img and shrink it so that writing back the a new microSD would not take an eternity.
I have both the 31 Gig file and the 5 Gig file.
Would like to see if the 5 Gig file can be put on microSD and expanded to boot on the Pi.
You can try but what are you gaining by using a clone of something you already have that’s got errors?
A fresh image install, then restore just your configs, would be better IMHO.
EDIT:
Have you tried to simply downgrade back to 2.4?