David's Astronomy - Notes 2022-10-14 (S1047)

David's Astronomy Pages
Notes - Session 1047 (2022-10-14)

Notes
(S1046)

Notes
Main

Home
Page

Notes
(S1048)

	2022-10-16

	Session Aims & Highlights
	- Observing Result - Night Summary Plot - Session Event Log

	Operational Issues
	- Critical Issues (0), Major Issues (2), Minor Issues (7), Small Defects (7), Continuous Improvement (23)

	Images from 2022-10-14 >> [ Local Files >> ]

	Zigbee Project
	ConBee II
	deCONZ
	Phoscon
	deCONZ - REST API
	deCONZ - WebSockets

	AllSky Camera - Earwig Problem

	2022-10-19
	.Net Framework 4.8
	SBIG Driver Observations

	2022-10-20
	Casting Observatory Alarms to Google Home Speaker

	2022-10-21
	Observatory Zigbee Network
	Zigbee-AstroMain Integration
	Conbee II - Firmware reinstall

Session Aims & Highlights (2022-10-14)

Main aims

Targets. Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by time & twilight conditions.

Equipment & Software

12" LX200 and ST-10XME
80mm APO and ZWO ASI 178MC
CCDApp2, TheSky6, CCDSoft5, DeviceHub 6.6.0.16, MeadeGeneric 1.3.5.414, UPB 1.5, ASCOM 6.6
Pegasus UPB & Motor Focus, TCF-S
SharpCap 3.2, PHD2 2.6.11dev2
AstroMain 3.55.4, AstroPlan 1.32.5, AstroShCap 1.3.12, AstroGuard 1.9
AstroVOE 1.12 AstroSN 1.8.6, AstroProtect 1.7, AstroMove 1.9.1
(AstroWeather 1.18.1, AstroAllSky 3.17.1, AstroObsCam 1.9, AstroLaunch 1.9.4)

Highlights

Targets. Data was acquired from 21 out of 33 planned targets, with partial data acquired from 1 further targets

Notes:

Start of session was delayed by a problem with the application of Rain Trim Setting. This also caused the first 3 targets to be missed/skipped.
Cloud (high cloud that reduced star count without dropping Cloud Sensor's Clarity value effected the session significantly and it was not until later 04:04 that sky was clear enough for productive observing.

Summary Plots & Logs

Observing Plan

Observing Result

Dome & Scope Slewing Performance

Slew/Centering Performance

Guiding Performance

Sky Conditions (Locate Frames)

Night Sky Summary Plot
Top axis: Sky Brightness at Zenith (in ADU/s)
Lefthand axis: Local Time (hh LT). Righthand axis: Sun Altitude (degs)

Actual Weather vs Pre-Session Weather Forecast

Session Event Log

Time	Event	Detail
19:41:03	Session Created	Session Created (Live, 2022-10-14 S01047, ImageSaveNum: 1047001)
19:41:06	Scope Switched On	Telescope Power has been switched on via UPB Powerbox.
19:41:21	Services Started	Observatory Services started
19:41:23	Observatory (Manual)	Observatory placed in Manual Mode
19:51:00	User Intervention	User Intervention to re-initiate Autostart after Scope.PowerState / Scope Connection issue
19:51:26	Scope Switched On	Telescope Power has been switched on via UPB Powerbox.
19:53:03	Services Started	Observatory Services started
20:00:56	Session Monitoring	AutoStart monitoring for Live Session opportunity between 20:00 & 05:41
20:00:58	Observatory (AutoStart)	Observatory placed in Auto-Start Mode
20:01:00	Session AutoStarting	Session autostarting (20:00)
20:01:28	Services Started	Observatory Services started
20:01:35	Observatory (Auto)	Observatory placed in Fully-Automated Mode
20:01:38	Session Pending	Session pending (2022-10-14)
20:01:41	Session Initiating	Session initiating (2022-10-14)
20:01:43	Plan Requested	Observing Plan requested from AstroPlan (1.32.5)
20:02:25	Plan Loaded	Observing Plan loaded to queue (Plan ID: 809)
20:02:40	Camera1 Connected	SBIG Camera connected (set point -20°C)
20:02:45	Telescope Connected	Telescope connected (TheSky6)
20:03:09	Session Equilibration	Session ready to Open Dome
20:03:55	Dome Opened	Dome opened (opening time 45s)
20:04:45	Session Running	Session running
20:04:47	Queue Started	Observing Queue started (33 targets selected)
20:04:50	Target Started (NrZen)	Target started (Focus Field 20, HIP 98535)
20:05:03	Dome Unparked	Dome unparked
20:09:23	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
20:12:05	Focusing Completed	Foc1 AutoFocus Completed (Profile No 1, wide)
20:14:22	Focusing Completed	Foc1 AutoFocus Completed (Profile No 1)
20:14:25	Focusing Started-Foc2	Foc2 Focusing Started (Secondary Scope, using ShCap)
20:16:33	Focusing Completed	Foc2 AutoFocus Completed (Profile No 2, wide)
20:18:15	Focusing Completed	Foc2 AutoFocus Completed (Profile No 2)
20:18:32	Target Completed (NrZen)	Target completed (Focus Field 20, HIP 98535)
20:18:37	Target Started (1/33)	Target started (1/33, GCVS BL Lac)
20:22:00	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
20:24:11	Focusing Completed	Foc1 AutoFocus Completed (Profile No 3)
20:28:35	Target Completed	Target completed (1/33, GCVS BL Lac)
20:28:39	Target Started (2/33)	Target started (2/33, IC 1132 w/SN2022prv)
20:33:31	Focusing Skipped	Foc1 focusing skipped - star is too dim (TCF-S)
20:50:08	Target Completed	Target completed (2/33, IC 1132 w/SN2022prv)
20:50:12	Target Started (3/33)	Target started (3/33, C/2022 E3 (ZTF))
20:54:40	Focusing Skipped	Foc1 focusing skipped - star is lost (TCF-S)
21:07:06	Target Completed	Target completed (3/33, C/2022 E3 (ZTF))
21:07:51	Target Started (4/33)	Target started (4/33, NGC 6701 w/AT2022nxe)
21:11:02	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
21:13:09	Focusing Completed	Foc1 AutoFocus Completed (Profile No 4)
21:29:09	Target Completed	Target completed (4/33, NGC 6701 w/AT2022nxe)
21:29:51	Target Started (5/33)	Target started (5/33, NGC 6745 w/SN2022prr)
21:31:10	Dome Slew	Dome slew held up at Az. 268.1, 267.7° (Total delay 54s)
21:33:53	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
21:36:07	Focusing Completed	Foc1 AutoFocus Completed (Profile No 5)
21:51:56	Target Completed	Target completed (5/33, NGC 6745 w/SN2022prr)
21:52:00	Target Started (6/33)	Target started (6/33, AT2022kl (CV))
21:54:57	Dome Slew	Dome slew held up at Az. 247.0, 246.9, 222.3, 221.7° (Total delay 125s)
21:57:14	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
21:59:25	Focusing Completed	Foc1 AutoFocus Completed (Profile No 6)
22:17:06	Target Completed	Target completed (6/33, AT2022kl (CV))
22:17:10	Target Started (7/33)	Target started (7/33, AT2022tru (CV))
22:21:03	Focusing Skipped	Foc1 focusing skipped - star is too dim (TCF-S)
22:37:17	Target Completed	Target completed (7/33, AT2022tru (CV))
22:37:21	Target Started (8/33)	Target started (8/33, AT2022xij (CV))
22:40:50	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
22:43:04	Focusing Completed	Foc1 AutoFocus Completed (Profile No 7)
22:49:15	Target Completed	Target completed (8/33, AT2022xij (CV))
22:49:20	Target Started (9/33)	Target started (9/33, GCVS SS Cyg)
22:52:24	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
22:54:22	Focusing Completed	Foc1 AutoFocus Completed (Profile No 8)
22:58:48	Target Completed	Target completed (9/33, GCVS SS Cyg)
23:04:56	Target Started (10/33)	Target started (10/33, Jupiter)
23:06:57	Dome Slew	Dome slew held up at Az. 222.6, 221.7° (Total delay 74s)
23:09:44	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
23:11:31	Focusing Completed	Foc1 AutoFocus Completed (Profile No 9)
23:15:40	Target Completed	Target completed (10/33, Jupiter)
23:16:21	Target Started (11/33)	Target started (11/33, WDS GRB 34)
23:19:34	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
23:21:32	Focusing Completed	Foc1 AutoFocus Completed (Profile No 10)
23:23:33	Target Completed	Target completed (11/33, WDS GRB 34)
23:24:24	Target Started (12/33)	Target started (12/33, NGC 7448 w/SN2022wsp)
23:27:40	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
23:29:51	Focusing Completed	Foc1 AutoFocus Completed (Profile No 11)
23:46:25	Target Completed	Target completed (12/33, NGC 7448 w/SN2022wsp)
23:46:29	Target Started (13/33)	Target started (13/33, NGC 157 w/SN2022jli)
23:50:58	Focusing Skipped	Foc1 focusing skipped - star is lost (TCF-S)
00:07:07	Target Completed	Target completed (13/33, NGC 157 w/SN2022jli)
00:07:11	Target Started (14/34)	Target started (14/34, C/2020 V2 (ZTF), ToO)
00:11:31	Focusing Skipped	Foc1 focusing skipped - star is too dim (TCF-S)
00:28:40	Target Completed	Target completed (14/34, C/2020 V2 (ZTF), ToO)
00:28:42	Target Missed (15/34)	Target's time slot was missed (15/34, AT2021vqu)
00:30:24	Target Started (16/34)	Target started (16/34, NGC 7495 w/SN2022ubb)
00:34:30	Dome Slew	Dome slew held up at Az. 247.1, 223.2° (Total delay 155s)
00:37:14	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
00:39:10	Focusing Completed	Foc1 AutoFocus Completed (Profile No 12)
00:55:58	Target Completed	Target completed (16/34, NGC 7495 w/SN2022ubb)
00:56:03	Target Started (17/35)	Target started (17/35, Jupiter, ToO)
01:01:00	Obs.Monitor Frozen	Obs.Monitor appears to be frozen at around 01:01 in section Monitor TheSky6 Scope
01:07:51	Target Completed	Target completed (17/35, Jupiter, ToO)
01:07:56	Target Started (18/35)	Target started (18/35, NGC 7594 w/SN2022de)
01:09:01	Dome Slew	Dome slew held up at Az. 217.6° (Delay 44s)
01:18:05	Target Completed	Target partially completed (18/35, NGC 7594 w/SN2022de)
01:18:09	Target Started (19/35)	Target started (19/35, UGC 12599 w/SN2022mhn)
01:21:01	Focusing Skipped	Foc1 focusing skipped - star is too dim (TCF-S)
01:36:57	Target Completed	Target completed (19/35, UGC 12599 w/SN2022mhn)
01:37:01	Target Started (20/35)	Target started (20/35, AT2022whd (CV))
01:40:45	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
01:42:42	Focusing Completed	Foc1 AutoFocus Completed (Profile No 13)
01:48:29	Target Completed	Target completed (20/35, AT2022whd (CV))
01:48:33	Target Started (21/35)	Target started (21/35, GCVS TT Ari)
01:52:34	Dome Slew	Dome slew held up at Az. 268.2, 267.5, 247.2, 223.2, 222.6° (Total delay 173s)
01:55:42	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
01:57:41	Focusing Completed	Foc1 AutoFocus Completed (Profile No 14)
02:04:51	Target Completed	Target completed (21/35, GCVS TT Ari)
02:04:56	Target Started (22/35)	Target started (22/35, AT2022oab (CV))
02:14:15	Target Completed	Target completed (22/35, AT2022oab (CV))
02:14:19	Target Started (23/35)	Target started (23/35, AT2022why)
02:15:08	SoftSuspend Called	Soft Suspend is called due to Deteriorating Conditions (too few stars)
02:17:48	SoftSuspend Cancelled	Soft Suspend is cancelled due to improved conditions
02:19:10	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
02:21:19	SoftSuspend Called	Soft Suspend is called due to Deteriorating Conditions (too few stars)
02:21:29	Focusing Completed	Foc1 AutoFocus Completed (Profile No 15)
02:27:20	Target Completed	Target completed (23/35, AT2022why)
02:27:22	Queue Paused	Queue paused for Session Suspension
02:27:25	Session Suspended	Session suspended
02:28:15	Dome Closed	Dome closed (closing time 50s)
02:35:02	Target Cancelled	Target cancelled (24/35, GSC 1224:29) due to cloud
02:46:12	Target Cancelled	Target cancelled (25/35, AT2022weo) due to cloud
03:00:12	Target Cancelled	Target cancelled (26/35, Nova Per 2020) due to cloud
03:20:42	Target Cancelled	Target cancelled (27/35, AT2021bpy) due to cloud
03:42:42	Target Cancelled	Target cancelled (28/35, AT2022vxe) due to cloud
04:04:42	Target Cancelled	Target cancelled (29/35, NGC 5894 w/SN2022pgf) due to cloud
04:18:42	Target Cancelled	Target cancelled (30/35, 29P/Schwassmann-Wachmann) due to cloud
04:38:42	Target Cancelled	Target cancelled (31/35, AT2022tmq) due to cloud
05:00:42	Target Cancelled	Target cancelled (32/35, UGC 2508 w/AT2022trp) due to cloud
05:22:42	Target Cancelled	Target cancelled (33/35, MCG -3-12-11 w/SN2022ucj) due to cloud
05:44:42	Target Cancelled	Target cancelled (34/35, UGC 6983 w/SN2022pru) due to cloud
06:19:02	Target Cancelled	Target cancelled (35/35, C/2020 V2 (ZTF)) due to too few stars
06:19:08	Queue Completed	Job Queue completed
06:19:14	Session Closing	Session closing
06:19:19	Dome Closed	Dome already closed (closed at 01:28, closing time 50s)
06:20:44	Dome Parked	Dome parked (parking time 77s), Az: 90.0 deg
06:21:54	Telescope Parked	Telescope parked (parking time 69s)
06:22:09	Telescope State	Scope parked Turn scope off. (Handbox)
06:22:32	Telescope Switched Off	Telescope Power has been switched off via UPB Switch.
06:23:26	Services Stopped	Night Services stopped
06:23:28	Session Housekeeping	Session Housekeeping started (Create Fits Summary, Transfer Files)
06:23:49	Session Finished	Session Finished

Session Alerts

Time	Alert	Detail
19:41:23	Telescope Alert	ASCOM Telescope not connnected
23:05:03	Anomalous Dome Slew	Dome slew resumed at Az 236.9° (T+1.6s)
00:34:38	Dome Discrepency	Difference between Dome Az and Slave Az is > 1 deg (NGC 7495)
01:01:36	Obs.Monitor	Obs.Monitor appears to be frozen in section Monitor TheSky6 Scope (last cycle at 01:01:00)
01:02:30	Obs.Monitor	Obs.Monitor has resumed again after 1.5 mins
01:37:08	Anomalous Dome Slew	Dome slew resumed at Az 236.1° (T+2.8s)

Operational Issues (2022-10-14, S1047)

Critical Issues (0)
Major Issues (2)
Minor Issues (7)
Small Defects (7)
Continuous Improvement (23)

[ Prev | Next ]

Critical Issues

None

Major Issues

AutoStart failed with the message "problem connecting to the ASCOM Telescope" and Observatory was returned to Manual Mode (19:41). After AutoStart selected Night Services and whilst Services were been started, there were failures for Telescope Power' service (with message 'Telescope Power is off') and Telescope, and with no connection to the ASCOM Telescope, the observatory was returned to Manual Mode as per design. The failure to wait the required 60s in order to make a connection is considered to be a major issue as without a user intervention to rerun 'Start Services' the session would not have run and no targets would have been acquired. Log file shows three messages at 19:41:04 'Checking Telescope Power State (0)', 'AutoStart Mode so proceed to Switch Scope Power On' and 'Telescope Power has been switched on'. These are all normal present messages but instead of then putting up the message ' WaitOn Scope | Waiting 60s to ensure telescope has finish initialising.' the message show that the start services moved directly onto checking the TelePosition service. It is unclear why the Start Telescope routine didn't wait the necessary 60s before attempting Telescope connection. Although log messages where normal up until the point that a 60s delay wasn't executed, the expected Report message when starting the Telescope Power service 'Ok Started (19:41) (ASCOM.pegasus_upb.Switch, Switch 0)' wasn't shown. Instead "Fail Telescope Power is off" was shown. Looking as UPB Software showed that the LX200 Power was On. Prehaps there was a timing edge case where read Switch (0) was still reporting False for a fraction of a second after the write Switch(0) had been set to True. Code should either make a short delay or make a number of repeat attempts before concluding that Switch(0) / Telescope Power was truely off. Examining code shows that scope power is switched on using the Scope.SetPowerOn_Quiet() routine which makes the call 'objPowerBox.SetSwitch(cSwitchPower1, True)' and a 'Scope Switched On' event is recorded in the 'events' table which is consistent with the observation that UPB Software shows that the LX200 Power Switch as being 'On'. The code then enters a loop which exits if Scope.PowerState becomes 1 (ie True) or the loop times out after 10s. In normal Scope.SetPowerOn Scope.PowerState is explicitly set to 1 but this isn't done by the Scope.SetPowerOn_Quiet() routine. Instead the loop has to wait for the ObsMonitor to set Scope.PowerState based on a query of objPowerBox.GetSwitch(cSwitchPower1). This might not happen if ObsMonitor was frozen (no evidence), bMonitorPowerBox = false (not indication) or PowerBox.bSwitchLockIsOn (possible but unclear why it would clear at somepoint during the 10s period). Fix attempted in AstroMain 3.55.5 (SetPowerOn_Quiet() routine modified to make up to 6 attempts to check objPowerBox.GetSwitch(cSwitchPower1) and set Scope.PowerState without requiring the variable to be set by ObsMonitor.
Fixed attempted 2022-10-14 (AstroMain 3.55.5, UPB Switch).
Unable to connect to Dome (2022-10-16, 21:30). Unable to connect to Pulsar Dome via DeviceHub.Dome from AstroMain or directly via DH. Pulsar ASCOM Log file shows CommandString Exception: "System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request."
and Volatile Exception: "System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request". Issue resolved after a visit to observatory. Unclear what finaly fixed the issue, but Pulsar Dome was power-cycled, and USB cables disconnected/reconnected. Eventually the Dome could be connected to ok. It is unclear was caused the problem to occur but delivery of Zigbee service now allows the Pulsar Dome to be Pulsar dome to be switched off/switched on via a REST-API calls, and a 'Restart Dome' function has been built into AstroMain which allows the capability for user to remotely restart the Pulsar Dome service (including a power recycle of the dome controller) or in future for ObsManager to automatically perform this operation under specific conditions such as failure to connect to Dome and presence of 'System.IO.IOException' exceptions. Closed after review 2022-11-10. A separate ticket has been raised (S1056) to add automated calls to 'Restart Dome' routine in the Dome Checking logic in AstroMain's ObsManager.
Closed after review 2022-11-10 (Pulsar Dome, deCONZ, AstroMain).

18:23:35.31 | Observatory Services Start DeviceHub Ok | Service already started (DeviceHub 6.6.0.16) 18:23:35.32 | Observatory Services Get DomeProfile Info | Retrieving Profile for ASCOM.Pulsar_Observatories_Dome.Dome 18:23:35.32 | Observatory Services Set DomePort Info | Setting COM Port to COM3 18:23:35.32 | Observatory Services Set DomeTraceLevel Info | Setting Trace Level to True 18:23:35.32 | Observatory Services Save DomeProfile Info | Saving Profile For ASCOM.Pulsar_Observatories_Dome.Dome 18:23:35.33 | Observatory Services Read PulsarDomeRecord Alert | Volatile Exception at 17:17:28 nExceptions=1 18:23:36.73 | Observatory Services Start DeviceHub.Dome Fail | Failed to connect (ASCOM.Pulsar_Observatories_Dome.Dome, 6.3.4)

Minor Issues

CCD Images show a number of Frost Slugs along the 'top' edge of the image (21:02). During the imaging of Target 3/33 (C/2022 E3 (ZTF) it was noticed that frost slugs were present on raw CCD images. CCD Desicator needs to be renewed ahead of next session.
Done 2022-10-15 (SBIG Camera).
Both attempts to image the target Jupiter took 4 attempts to center the planet. Modifications to Bright Object Centering were previously made so that in case of Jupiter (and also Mars & Saturn), SExtractors Detection Aperture would be enlarged to ensure the planet object was being used for centering rather than the brightest moon or offset star. This more or less works but isn't perfect. In case of Target 10/31 (oid 11), the Jupiter was correctly identified as brightest object in Locate Frame 1 (with a 5.14' pointing /slew error) and the planet was correctly centered based on visual examination of the Locate Frame 2, however this time the planet wasn't identified as the brightest object and instead one of Jupiter moons was identified as the brightest object. Jog corrections centered this moon based on visual examination of Locate Frame 3, but at the expense of moving Jupiter away from the centre. Jupiter was correctly identified as brightest object and the jog correction more or less correctly centered the planet in Locate Frame 4 but this time a blooming spike coming off Jupiter was mis-identified as the brightest object and the final pointing error was reported as 0.22' . In case of Target 17/31 (oid 18), Jupiter was correctly identified as brightest object in Locate Frame 1 (with a 3.88' pointing /slew error) and the planet was more or less correctly centered based on visual examination of the Locate Frame 2, however this time the planet center wasn't identified as the brightest object but instead part of blooming spike coming off Jupiter was identified as the brightest object. Jog corrections centered this blooming spike point based on visual examination of Locate Frame 3. Jupiter was correctly identified as brightest object and the jog correction correctly centered the planet in Locate Frame 4 where again the blooming spike was mis-identified as the brightest object and the final pointing error was reported as 1.12'. Unclear why brightest moon was selected as brightest object in Locate Frame 2 of the first case. It is supposed that the blooming spike 'artifically lowered the apparent flux from the planet object. Modification made to the 'Select Locate Exposure Time' code in GetBrightStarExposureTime() routine in AstroMain 3.55.6 to select an exposure time of 0.12s for Jupiter instead of 0.2s, in order to suppress the blooming spike.
Fixed 2022-10-15 (AstroMain 3.55.6).
AstroMain DomeMonitor is logging messages every 5 or 10s, implying Dome is making small 0.1 deg movements whilst it is parked (2022-10-18). Examples of the messages are being logged :
09:04:32.21 | Report Dome.Movement Ok | Dome has moved 0.1 deg (Az 90.1 -> 90.0) 09:05:32.05 | Report Dome.Movement Ok | Dome has moved 0.1 deg (Az 90.0 -> 90.1) after being stationary for 1.0 mins
ASCOM logs should Volatile message with dome azimuth changing to and fro between 90.0 and 90.1. Since this is the data that Pulsar Dome provides because this is probably a rounding or analogue to digital effect in the Dome Controller, and not a physical movement of the dome drive, the issue is best handled by modifying the Dome Monitoring routine to ignore changes as small as 0.1 deg. Fixed in AstroMain 3.56.
Done 2022-10-18 (AstroMain 3.56).
AstroGuard producing multiple 'not implemented in this driver' exception messages (2022-10-18). Whilst experimenting with operation of Smart Plug for the Pulsar Dome mutiple messages 'Exception in Main Loop. Property read ASCOM.DeviceHub.Dome ShutterStatus is not implemented in this driver' were produced whilst AstroGuard was still connected to DeviceHub.Dome and the power to Pulsar Dome was switched off.
Resolved (AstroGuard 1.10).
There were delays during slewing to certain targets due to holdup in the Dome Rotation. Holdups occurred at Az 268° (54s), 218° (44s), 222° (74s), 222° & 247° (125s), 223° and 247°(155s) 223, 247 & 268° (173s), 247° (24s). It was later discovered that poor dome slewing performance was due to a loose drive wheel on one of the dome rotation motors (see Pulsar Dome - Loose Rotation Drive Wheel, 2023-10-27). Replacement Drive Wheel & Connector were eventually installed in the Observatory in Nov 2023 and this resolved the issue (See Pulsar Dome - Replacement Rotation Drive Wheel, 2023-11-17 ) wh
Resolved 2023-11-17 (Pulsar Dome).
Firmware on Conbee II USB stick were accidently corrupted through an attempt to running newly installed ZShark software (2022-10-22). ZShark (win/zshark_V1_0501.exe) was installed on the Observatory Computer with the aim of eventually using it to sniff out the button event numbers associated with a future 4 button smart remote controller. After innitial attempt to run the ZSHark program failed (itw would find the Conbee II device). It was thought thise might be because deCONZ was running so after closing deConz a second attempt was made. ZShark indicated that the device on COM7 occupied by the Conbee 2 USB Stick) was missing firmware and asked to proceed to install firmware. With no more than a slight though that this was probably something zShark needed to add, 'OK' was clicked and something was presumably installed on the Conbee II. This proved to be a major mistake, whilst ZShark appear to then connect and at least 2 packages were passed, I was left unsure what I needed to do next and resigned myself that I would need to look at setup / running of zshark in more detail and closed the program. deCONZ was restarted but it fail to connect to the Conbee 2 device. Multiple attempts were tried to connect. Including removal and reinserting of the USB stick. With deCONZ is running but apparently not conneced to the Conbee II device, REST API (Get) calls seem to superficially work (they return values from when the Conbee II was last working) but REST API (Put) give an httpResponse containing an error of type 901 (Intenal error 951). So it seems that the firmware on the Conbee 2 has become corrupted and prevents the use of the Observatory's Zigbee Network until the necessary firmware is reinstalled on the Conbee II. It is likely that the network devices (SMmart Plugs and Open/Close Sensors) will have to be potentiallly all reset and re-attached to the network. It is unclear if back-up made earlier in Phoscon will allow the process to be shortened the process. (see Conbee II - Firmware reinstall, 2022-10-22)
Fixed 2022-10-22 (Conbee II / deCONZ).
AstroMain unable to connect to Pulsar Dome (2022-10-22). AstroMain unable to connected to Pulsar Dome and ObsViewer drawing roll-off roof style observatory rather a dome. Issue occurred after a corruption of the Conbee II firmware / failure of the zigbee network , and a restart of AstroMain. Problem still occurring after restarting Device Hub. The problem might have been caused by a temporary USB cable disconnection associated with work on the USB Hub which saw an adjacent USB Cable (connecting to Combee II stick ) being taken out and reinserted into the USB Hub . Issue resolved by manually powering off & powering on the Pulsar Dome from wall plug. The same problem happened again later in the day after Conbee II issue had been resolved and the Pulsar Dome smart plug reconnected to Observatory's Zigbee network (this time the issue was resolved using the 'Restart Pulsar Dome' button routine from AstroMain Observatory/More/Dome tab. Problem is similar to the major issues logged 2022-10-16, 21:30 , which occurred before getting a Smart Plug for Pulsar Dome & before creating deCONZ Zigbee network. Same or similar issue occurred the following day (2022-10-23) and it was established that the most-likely cause of recent problems was due to a Zigbee Network Setup mistake whereby Pulsar Dome and Dehumidifier were place in the same 'Light' group.
Resolved (Pulsar Dome / AstroMain).

Small Defects

The Dome Already Closed Time written Dome Closed Event at end of session wasn't converted to a Local Time. The Dome Closed event written during Closing Session showed 'Dome already closed (closed at 01:28...)'. The dome was in fact closed at 02:28. The UT time isn't being converted to a Local Time here even though the correct local time is reported in the session's Report file. This issue was introduced during recent changes for improving DST Handling and was either missed in the last 2 sessions or it didn't crop up.
Done 2022-10-15 (AstroMain 3.55.6).
The Report message for 'Set Detection Aperture' contains typographical & grammatical errors and should be corrected. When Detection Aperture for centering Locate Frames for Jupiter is set the associated report messages "(PHOT aperture set to dimaeter to 45 pixels)" and "(PHOT aperture set to dimaeter to 8 pixels)" contain a typographical error for the word diameter and the grammer is also incorrect. Fixed in AstroMain 3.55.6 so the message now reads "(PHOT aperture set to diameter of 45 pixels)". The associated Logfile message also contained the same typographical error and has also been fixed.
Done 2022-10-15 (AstroMain 3.55.6).
The Observatory Alarms Web App is showing a countdown time that is incorrect by one hour. With a current time of 12:30:00 (BST) and an alarm set for 12:32:00 (BST) the CountDown time shows as 01:02:00 instead of 00:02:00. Fixed 2022-10-20 by employing a new function GetTimeDiffHHMMSS (timespan).
Fixed 2022-10-20 (Observatory Alarms Web App).
The 'Obs T.' value on AstroMain's ObsViewer intermittently changes a blank (2022-10-21). It is unclear if this is a related to changes in AstroMain 3.56 which includes new code for inserting flags for Shutter & Obseratory Door sensors. A new ManageDehumidifier() routine will in future access the Env.ObservatoryTemperature but this property wouldn't have been read yet by this routine as the relevant codeline doesn't get executed until a new Smart Plug for Dehumidifier has been installed and the device becomes "reachable". Examination of DrawObservatoryPicture() code would indicate that if the field changes to a blank it is because Env.DataIsValid(EProp.WeatherStation) is false, whilst if field changes to "--" it is because Env.DataIsValid() is True and Env.ObservatoryTemperature is vcNull. Env.DateIsValid(EProp.WeatherStation) returns false when WeatherData.Valid is false. This could be intermittently going to false when TimeNow - TimeLastValid >= TimeOutPeriod. (TimeNow - TimeLastValid is not DST friendly or not (this is raised as issue under a separate ticket). TimeOutPeriod is currently set to 1 minute (1/60 hour). Fixed attempted in AstroMain 3.56.1 by setting TimeOutPeriod to 2 minues (2/60 hour).
Fixed 2022-10-21 (AstroMain 3.56.1).
Modify the recording of WeatherStation records and calculation of whether data has timed (DST Issue). WeatherData.Valid (true/false) is currently determined by the equation 'TimeNow - TimeLastValid >= TimeOutPeriod' . TimeNow is decimal hours built up from now() datetime, TimeLastValid is similarly a decimal hours value built up from now() datetime as the time that Weather Data record was recieved, so it is inherently not DST Friendly, and could give an incorrect value when crossing a change in Daylight Saving. Whilst the duration of the issue may be very short (probably just 2 or 3 minutes long) is is incorect and sholuld be fixed. TimeLastValid and TimeNow should be changed to DateTime type (instead of Double) and should each be generated from DateTime.UtcNow()
Fixed 2022-10-21 (AstroMain 3.56.1).
Pulsar Relay flag/traffic light not working correctly on AstroMain's ObsViewer (2022-10-21). After installing new 3.56 version of AstroMain with Shutter & ObsDoor sensor access & flag displays the Pulsar Relay is shown as a white flag with "--" text. The CS Relay is working ok. Examining code no flag would indicate Dome.RelayFlag is vcNull, whilst a white flag with '--' text would indicate that Dome.RelayFlag has a value that is not fRelaySafe (0), fRelayUnSafe(1) or vcNull (-99). The Dome.RelayFlag is obtained either by reading Volatile message from Pulsar Dome via DH.Dome or read from the volatitle lines in the Pulsar Dome ASCOM log file. The Relay flag is the last field in the record. Investigating show that RelayFlag had the value 2, which has not been seen before. It seemed that the RelayFlag turned from 1 to 2 when the Dome connection was restarted at around 12:32 today (2022-10-21). It is unclear if the relay cables where knock around this time, as some changes where being made in the observatory at around this time point. Issue was fixed in evening 2021-10-21 by rebooting the Pulsar Dome Controller. This was done remotely over VNC using AstroMain's recently added buttons 'Turn Off Pulsar Dome' & 'Turn On Pulsar Dome' that make REST API call to the Observatory's Zigbee Network that turn off / turn on a Smart Plug that feeds the Pulsar Dome. It would seem that RelayFlag=2 is likely a Error Value. AstroMain 3.56.1 has been modified to show a magenta coloured flag for fRelayError (2).
Fixed 2022-10-21 2022-10-20 (AstroMain 3.56.1).
AstroMain's ObsViewer drawing roll-off roof style observatory rather than a dome observatory (2022-10-22). AstroMain was unable to connect to Pulsar Dome and ObsViewer began drawing roll-off roof style observatory rather a dome. The issue occurred after a corruption of the Conbee II firmware & failure of the zigbee network , and a restart of AstroMain / new connection to Dome. ObsViewer should always draw a dome observatory (regardless of issues connecting to dome). Same issue happened at 2022-10-23 16:53 when a new Dome connection was attempted whilst there was an issue with Dome Connection and the Pulsar Dome driver was reporting Volatile exceptions.
Fixed 2022-10-23 (AstroMain 3.56.2).
ObsViewer Flag and Observatory/More tab flag are showing apparently connected zigbee device even though zigbee network is down due to corrupted Conbee II stick. ObsViewer shows red or green coloured flag for the Smart Plug and Sensor connected equipment (except Dehumidified on Obs Viewer which shows as magenta flag, but then has 'Dehumidifier On' text. With deCONZ running but apparently not conneced to the Conbee II device. REST API (Get) calls appear to work in that they return values from when the Conbee II was last working, this is why the Flags appear as they do. Prehaps the Monitoring of deCONZ equipment should consider the lastseen or lastupdated time, or the presence of events coming through from a websocket and if none of the devices have recent data consider that the network isn't active for some reason and set '.Valid' and '.Reachable' to False. When deCONZ is closed the Flags turn to white as per design (as all REST API calls fails through '0 server error'). Expectation is that the flag are a magenta colour when there is an issue or problem. ReportZigbeeNetwork() modified in AstroMain 3.58 to report the time since each device was last seen, and to to summarise the state of the network, raising an alert if the latest last seen time from any device was more than 5 minutes ago.
Part Fixed 2022-11-19 (AstroMain 3.58).

Continuous Improvement

Install deCONZ application onto the Observatory Computer. DeCONZ is control software, which will be used to control an Zigbee network running in the Observatory via a Conbee 2 USB stick attached to the Observatory Computer allowing equipment like the SBIG Camera and Pulsar Dome to be power-cycled via Philips HUE Smart Plugs in order to rectify particular device issues. The feasibility of power cycling of equipment using REST API's sent from AstroMain to DeCONZ was proven on Development Computer on 2022-10-15. Version 2.18.2 of deCONZ
Done 2022-10-16 (AstroLaunch 1.10).
Setup Zigbee Network on Observatory Computer for operating observatory's smart plugs. DeCONZ and Phoscon were used to create a zigbee based network for operating the power supply to selected observatory equipment (Aux Light (ID=2) and SBIG Camera (ID=3) ) using Philips HUE Smart Plugs. Operation of the network is via a Conbee 2 USB stick (COM7) inserted into the USB Hub connected to the Observatory Computer, using REST API's with an API Key that is specifically created for the gateway.
Done 2022-10-16 (Observatory, Observatory Computer, deConz).
Add deCONZ to the applications that can be launched from AstroLaunch's Observatory tab. DeCONZ is control software, which will be used to control an Observatory Zigbee network via a Conbee 2 USB stick allowing equipment like the SBIG Camera and Pulsar Dome to be power-cycled via Philips HUE Smart Plugs in order to rectify particular device issues. The deCONZ.exe executable unfortunately doesn't return its version number when interrogated. To get around this the deCONZ Setup file like 'deCONZ_Setup_Win32_V2_18_02.exe' is copied into the deCONZ program folder and renamed as 'deCONZ_Setup_Win32.exe' and this is then interrogated for program version number, since this does return the version number. This is a manual step that has to be remembered when installing a new version but its a viable workaround.
Done 2022-10-16 (AstroLaunch 1.10).
Add Buttons and Control Routines to AstroMain to operate Smart Plugs (lights) on the Observatory's Zigbee Network. Rest API used to change the On State of Smart Plugs (for SBIG Camera and Aux Light). Implemented in AstroMain 3.56. Buttons added to Observatory/ More Tab that allow 'SBIG Camera' to be Power Cycled and allow '240v Aux Light' to be turned on/turned off via local or remote control. In due course code will be added to allow AstroMain ObsManager/Queue Executor to power-cycle the SBIG Camera to resolve occasional, but show-stopping, glitch with the Camera, that prevents capture of image using the SBIG Camera and/or lock up the ObsMonitor.
Done 2022-10-16 (AstroMain 3.56).
Change routine behind the Aux Light button in AstroObsCam so that 240v Aux Light can be turned on/off using a REST API call to deCONZ. Current Aux Light button uses ASCOM Switching of Pegasus USB Command Hub to turn on/off a USB LED Light. (this is proved too dim to be useful). Routines for controlling 240v Aux Light can be copied from those developed for AstroMain 3.56
Done 2022-10-17 (AstroObsCam 1.10).
Add Buttons and Control Routines to AstroMain to operate a Smart Plug to control power to Pulsar Dome. In preparation for the arrival of a new HUE SmartPlug on the Pulsar Dome Power supply add 'Switch On / Switch Off' buttons to Observatory / More tab with routines to send REST API to lights/4 to change state of the power supply to Pulsar Dome, allowing the Pulsar Dome Controller to be power-cycled to resolve an operational glitch that have been known to occasionally occur.
Done 2022-10-16 (AstroMain 3.56).
Modify AstroMain's Dome.RestartDome() routine to include a Power Reset of the Pulsar Dome Controller. Modify Dome.RestartDome() routine to include a SwitchOffDomePower() / SwitchOnDomePower() cycle. Because the Power Reset operation takes some 20s (a 15s delay after switching off the power allows the Dome Controller to fully power down) AstroGuard needs to be modified to allow more time (30s increased to 40s) before making it's Dome reconnection.
Done 2022-10-17 (AstroMain 3.56, AstroGuard 1.10).
Modify AstroMain's RestartCCDSoft() routine to include a Power Reset of the SBIG Camera. Modify RestartCCDSoft() routine to include a SwitchOffSbigPower() / SwitchOnSbigPower() cycle. After switching on SBIG Camera a 15s delay after switching off the power allows the Dome Controller to fully power down) AstroGuard needs to be modified to allow more time (30s increased to 40s) before making it's Dome reconnection.
Done 2022-10-17 (AstroMain 3.56, AstroGuard 1.10).
Modify the name of the Observatory's zigbee (Conbee 2 / deCONZ based) network. Network was given the default name 'Phoscon-GW'. Using the Phoscon App the name of the network was changed to "AstroGW".
Done 2022-10-18 (deCONZ / Observatory).
Order and install a new Smart Plug to allow Pulsar Dome to be rebooted under remote or automated control. A new Philips HUE Smart Plug ordered from Amazon (2022-10-16) and after delievery was installed in observatory as 'Light' Node 4 on observatory DeCONZ network (2022-10-18). Operation of Pulsar Dome power state from AstroMain tested 2022-10-18.
Done 2022-10-18 (Observatory).
Add extra code to prevent Camera exceptions and prevent invalid imagery appearing when RestartCCDSoft operation occurs. New code added to TakeImageASync that allows execution to enter a Wait Loop if bRestartCCDSoft flag is raised. New flag bSkipCurrentCCDSoftImage created to indicate situations where Image may been aborted or failed when RestartCCDSoft operation occurs after the exposure ok.
Done 2022-10-19 (AstroMain 3.56).
Install Google Chrome on Observatory Computer in order to potentially cast Alarms & Alert Sounds to Google Home speaker.
Done 2022-10-19 (Observatory Computer / Observatory Alarms).
Add Chrome to the applications that can be launched from AstroLaunch's Observatory tab. Google Chrome browser is to be used to cast Observatory Alerts and Alarm Sounds from Observatory Computer to Google Home speaker. Having a facility to quickly and conveniently launch Chrome browser on Observatory Computer would be a handy feature. Added to AstroLaunch 1.10.1. This launches 64-bit version of chrome at the file path "C:\Program Files\Google\Chrome\Application\chrome.exe". The existing 32-bit version of Chrome on Development Computer (at \Program Files (x86)' ) was removed and the 64-bit version installed for compatibility with the version installed on the Observatory Computer.
Done 2022-10-19 (AstroLaunch 1.10.1).
Consider the cost/benefit on employing a smart plug to automate the operation of observatory's dehumidifier. A small dehumidifier (a christmas present a couple of year ago) is used in the observatory to help reduce its interior humidity. The dehumidifier is currently used with a Power Plug Timer, set so that it operates during a specific time window during the day. This is to avoid it running at night time when the observatory might be open. This doesn't allow for operation during evening/night time when the observatory isn't open (because it is overcast outside) and doesn't disable the dehumidifier from operating during daylight times when humidity is low. Without manual interventation the operational window doesn't change from winter to summer. A smart plug connected to the observatory's zigBee network could alllow much smarter use of the dehumidifier, with better chance of maximising its use when humidity is high, and eliminating its use when humidity is low. Decision made on 2022-10-19 to proceed with the ordering of an additional Philips HUE Smart Plug for use with Dehumidifier (ordering and installation is raised as a separate continuous improvement ticket)
Done 2022-10-19 (Observatory / Dehumidifer ).
Add Shutter Sensor, Observatory Door Sensor and Dehumidifier Flags to AstroMain's ObsViewer. After installation of a shutter open/close sensor and the forthcoming arrival and installation of a observatory door open/close sensor and a smart plug for the observatory's dehumidifier modify ObsViewer routine to plot appropriate traffic light flgs and text to ObsViewer window and resulting ObsPic pictures nsider the cost/benefit on employing a smart plug to automate the operation of observatory's dehumidifier. Changes made to AstroMain 3.56. A "LB" flag is posted next to flags for Shutter and Observatory Door if there is a battery warning for the sensor defined as battery levels < 30%.
Done 2022-10-21 (AstroMain 3.56 / ObsViewer).
Add Code to AstroMain's ObsManager to control the automated operation of the observatory's dehumidifier. Add new rule-based code to control the on/off operation of the observatories dehumidifer. Parameters that will be used to inform the AI will include shutter status, door status, session type, humidity, temperature.
Rules to include don't run dehumidifier when shutter open or when door open or when humidity is below a threshold value or when temperature is below freezing and may also when session type = live ?. Implemented 2022-10-20 including addition of fields on More/Dome table and associated VM properties in order to support Dehumidifier operation such as Current State, Auto checkbox and Humidity Threshold.
Done 2022-10-21 (AstroMain 3.56).
Order and install a zigbee Door/Window Sensor to provide assurance that the Dome's shutter is fully shut. There have been incidents in the past 2-3 years when the shutter on the observatory's dome hasn't been fully closed even though the Device Hub/Pulsar Dome is reporting it to be closed. AstroMain can be modified to query the shutter state from the zigbee sensor and use it for sending an alarm or making other interventions that might be appropriate. Experience with installation and operation of a shutter sensor will be helpful for the consideration of a further door/window sensor to indicate that the observatory door has been left open or has been unexpectedly opened (see separate ticket item). A Zigbee Sensor (Aqara MCCGQ11LM Door & Window Sensor, https://www.amazon.co.uk/Aqara-MCCGQ11LM-Door-Window-Sensor/dp/B07D37VDM3) was ordered 2022-10-17. Sensor arrived 2022-10-19 and was successfully installed on the observatory's zigbee network (AstroGW) as sensor 2. The sensor properties record type=ZHAOpenClose, manufacturer=LUMI, modelid=lumi.sensor_magnet.aq, swversion 20161128. Besides the open state (true/false), the sensor also provides temperature to whole number of degC in format like 1300 (for 13 degC) and a battery percentage (currently 100). It is uncertain how often temperature value is updated. There is a risk that the sensor proves unsuccessful in the realworld due to cold temperatures affecting battery performance (the sensor uses a single 3V CR1632 battery) or damp/water affecting the sensor unit or difficulty in permanently fixing the sensor in the required position (3M adhesive strips shouldn't come loose, but may). The sensor was installed on Dome's shutter on 2022-10-21. AstroMain (3.56) has been setup to read the sensor open/close state via REST API calls to observatory's zigbee network, and display its status in ObsViewer. There is an option for adding a further open/close sensor in the top of the roof for detecting when the Dome Shutter is fully open (This was eventually ordered and installed in observatory in Nov 2023, See S1162).
Done 2022-10-21 (deCONZ / Observatory / Shutter Sensor).
Consider the cost/benefit of employing a zigbee Door/Window Sensor to monitor the Open/Closed status of the Observatory Door. There have been incidents in the past 2-3 years when the shutter on the observatory's dome hasn't been fully closed even though the Device Hub/Pulsar Dome is reporting it to be closed. AstroMain can be modified to query the shutter state from the zigbee sensor and use it for sending an alarm or making other interventions that might be appropriate. Experience with installation and initial operation of a shutter sensor will be helpful to consideration of a further door/window sensor to indicate that the observatory door has been left open or has been unexpectedly opened. There is a risk that the sensor is unsuccessful in the realworld due to cold temperatures affecting battery performance or damp/water affecting the sensor unit or difficulty in permanently the fixing sensor in the required position (adhesive strips may come loose ?). A Zigbee Sensor (Aqara MCCGQ11LM Door & Window Sensor, https://www.amazon.co.uk/Aqara-MCCGQ11LM-Door-Window-Sensor/dp/B07D37VDM3) was ordered 2022-10-19 and is due for delivery 2022-10-21.
Done 2022-10-19 (deCONZ / Observatory / Door Sensor).
Modify AstroMain's ObsMonitor / ObsViewer to show status of Shutter's Open/Close Sensor. Traffic light should show an alert (Purple) when the Dome reports shutter is closed when the zigbee sensor reports that shutter is actually open (not closed). Experience from the installation and operation of a shutter sensor (already ordered) will be helpful to consideration of a further door/window sensor to indicate that the observatory door has been left open or has been unexpectedly opened. AstroMain also modified to access and use the state of Observatory Door's open/close sensor.
Done 2022-10-20 (deCONZ / Observatory / AstroMain 3.56).
Show a magenta coloured Dome Shutter Status flag when status is 'Error' / 'Unknown'. Flag is currently show Red when sensor state is error/unknow but a magenta coloured flag can be used to to indicate an "alert" (ie something anomalous)..
Done 2022-10-21 (AstroMain 3.56).
Order and install a zigbee Door/Window Sensor to provide assurance that the Observatory Door is shut. A Zigbee Sensor (Aqara MCCGQ11LM Door & Window Sensor, https://www.amazon.co.uk/Aqara-MCCGQ11LM-Door-Window-Sensor/dp/B07D37VDM3) was ordered 2022-10-19 and is due for delivery 2022-10-21. After arrival sensor was successfully installed on the observatory's zigbee network (AstroGW) as sensor 5 (since sensor 3 & 4 are taken up by Phoscon VPIR Test Control (Type=CLIPPresence) and Phoscon FSM_State Test Control (Type=CLIPGenericStatus)). There is a risk that the sensor proves unsuccessful in the realworld due to cold temperatures affecting battery performance (the sensor uses a single 3V CR1632 battery) or damp/water affecting the sensor unit or difficulty in permanently fixing the sensor in the required position (3M adhesive strips shouldn't come loose, but may). The sensor was installed on the Observatory Door on 2022-10-21. AstroMain (3.56) has been setup to read the sensor's open/close state via REST API calls to observatory's zigbee network, and display its status in ObsViewer.The new sensor was fix appropriately on the Observatory Door on 2022-10-21 and its operation successfully tested with AstroMain.
Done 2022-10-21 (deCONZ / Observatory / Door Sensor).
Order and install a new Smart Plug to allow the observatory's Dehumidifier to be switched on/off under automated control. A new Philips HUE Smart Plug had ordered from Amazon (2022-10-19) and was delivered 2022-10-21. The new Smart Plug will be installed in observatory as 'Light' Node 5 on the Observatory's DeCONZ network, and successfully tested with AstroMain, including automated operation of Dehumidifier using ObsManager's new ManageDehumidifier () routine.
Done 2022-10-21 (deCONZ / Observatory / Dehumidifier).
Show VNC tab on AstroLaunch on Observatory Computer. This is to allow a vnc connection to be conveniently made with the AllSky/Weather ComputerVNC connection to self (ie the Observation Computer) should probably be hidden. The vnc connection utilises the a file 'Laptop7.vnc'. This file should be copied over to the Observatory Computer desktop. AstroLaunch also modified to include an Admin tab on the Observatory Computer and AllSky Computer with useful button routines for quickly closing Folder windows and ACDSee folders. (these are based on the functionality of the Admin tab in AstroMove which is used on the Development Computer).
Done 2022-10-21 (AstroLaunch 1.10.2).
Change name of Zigbee Network Coordinator from "Configuration tool 1" to "ConBee II". Initially it was clear how to do this, but the name data is a parameter/field in 'lights/1' . Name was changed with a REST CALL : PUT https://{{ObsPath}}/api{{ApiKey}/lights/1 with the payload body {"name": "COnBee II" } (See Observatory Zigbee Network)
Done 2022-10-22 (deCONZ / Zigbee Network).
Order and install a zigbee 4-button Remote Controller for operation of selected observatory functions. A battery operated, 4-button remote controller (NEDIS ZBRC10WT Smart Remote Controller, 6.6cm x 3.4cm x 1.2cm in size, CR 2032 battery) has been ordered from Amazon on 2022-10-19 (https://www.amazon.co.uk/dp/B087QSD3VC/ref=pe_27063361_485629781_TE_item ) for delivery around 2022-11-01. Consideration will be given to a number of ideas about how the remote controller will be used for operation of the observation. Upon arrival the remote controller will be installed on the observatory's zigbee network. It is understood that switch/button type devices will be installed as sensors of type ZHASwitch, but that remains to be confirmed. There is a risk that the controller is difficult or impossible to install or operate on the DeCONZ / Phoscon based network (see 4 Button Zigbee Remote Controller ) . Nedis 4-button keyfob remote arrived 2022-10-31 and installation attempted, but wasn't able to get it installed via Phoscon. Whilst device appeared as a node of type 'IAS Ancillary Control Equipment' in deCONZ, it wasn't accessible as a sensor or other id'ed device, and couldn't be changed or referenced using Rest API. (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1139 & https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1323 ). A new ticket has been raised 2022-11-01 to try explore methods of accessing button press events from 4-button remote.
Moved to new CI 2022-11-01 S1051 (deCONZ / Observatory / Remote Controller).
Understand how to run deCONZ on Windows without GUI. Apart from when viewing network detail or need to set up new devices or other changes to the network, it is the user doesn't need to see the GUI interface, and if it would be helpful if it was hidden. REST API documentation suggests that deCONZ can be run without a GUI (assumingly this would as a service instead), but it isn't clear exactly how this is done). Following link https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters#available-debug-parameters indicates that opening deCONZ from command line with the following parameter '--platform minimal' can be used to start deCONZ in a headless mode (ie without GUI). Parameter is left out if GUI interface is required. (Using '--auto-connect=1' make deCONZ automatically connect). Tried making a Shortcut 'deCONZ_Headless' with a shortcut address set to ' "C:\More Programs\deCONZ\bin\deCONZ.exe" --platform minimal --auto-connect=1' but this gives the a deCONZ error dialog "This application failed to start because no Qt platform plugin could be initalized. Reinstalling the applications may fix this problem. Available platform plugins are: windows." The error message appears whether using '--' or just a single '-' in the parameter list entry. A question has been posted to the deCONZ community forum https://forum.phoscon.de/t/starting-deconz-without-gui-on-windows/2626/2 . Apparently the problem is due to the missing Qt platform plug-in and this will be integrated in the next version of deCONZ software according to Gautama (Phoscon). Ticket closed 2024-03-27 as no solution has been discovered, and in practice using deCONZ with GUI is not an issue.
Ticket closed 2024-03-27 (deCONZ, Windows).

[ Prev | Next ]

ZigbeeNet
Initially an initial attempt was made utilise ZigbeeNet Package
(GitHub : https://github.com/Mr-Markus/ZigbeeNet/wiki & Nuget: https://www.nuget.org/packages/ZigbeeNet/ )).

Although ZigbeeNet packages downloaded and incorporated into my VS project ok, it was possible to continue development as it wasn't possible to successfully connect with ConBee2 stick. Attempted on two separate occasions, but in the end went for a deCONZ based solution.

See deCONZ notes below

ConBee II

ConBee II is a USB stick providing a universal Zigbee gateway.

It offers a cloud free solution that unites Zigbee devices of many vendors.
Operation is at radio frequency of 2.4 GHz, and has a strong signal range via power-amplifier (200 m in free line of sight)

Product Page : from Phoscon, https://www.phoscon.de/en/conbee2 )

deCONZ

deCONZ (v 2.13.4) already installed on Development Computer

deCONZ (v 2.18.2) installed onto Observatory Computer today (2022-10-16)

Path : "C:\More Programs\deCONZ\bin\deCONZ.exe"

REST API

https://dresden-elektronik.github.io/deconz-rest-doc/

https://dresden-elektronik.github.io/deconz-rest-doc/getting_started/

ObsComputer : 192.168.1.75

"ApiKey": withheld

' Get All Lights Details

http://192.168.1.46:80/api/{{ApiKey}}/lights GET

{
"1": {
"etag": "bd01f4b753cb4dd698b7a1439d38d875",
"hascolor": false,
"lastannounced": null,
"lastseen": "2022-10-15T21:16Z",
"manufacturername": "dresden elektronik",
"modelid": "ConBee II",
"name": "Configuration tool 1",
"state": {
"reachable": true
},
"swversion": "0x26580700",
"type": "Configuration tool",
"uniqueid": "00:21:2e:ff:ff:07:97:0e-01"
},
"2": {
"etag": "c8d1c62fe2d443472bbf9abd734d2e61",
"hascolor": false,
"lastannounced": null,
"lastseen": "2022-10-15T21:16Z",
"manufacturername": "Philips",
"modelid": "LOM009",
"name": "Observatory Aux Light",
"state": {
"alert": "none",
"on": false,
"reachable": true
},
"swversion": "1.93.6",
"type": "On/Off plug-in unit",
"uniqueid": "00:17:88:01:09:d6:06:67-0b"
}

Get Light 2 details

http://192.168.1.46:80/api/{{ApiKey}}/lights/2 GET

Turn Light On/Off

http://192.168.1.46:80/api/{{ApiKey}}/lights/2/state PUT

{ "on": true }

{ "on": false }

Hue Smart Plug reset

1) Plug it in.

2) Wait for the light on the front top right to go off.

3) Hold the button until the light flashed orange five or more times.

4) Let go of the button

5) Open app and tap add device

Phoscon App

Notes to be added.

deCONZ - REST API

Notes to be added.

deCONZ - WebSockets

Notes to be added.

AllSky Camera - Earwig Problem

A new family of earwigs have taken up residency inside the AllSky Camera housing. There are ventilation holes between the camera housing and the hemisphere and at nighttime the earwigs are coming through the holes and climbing over the fish-eye lens. The following picture shows 3 of them.

Shining a torch into the hemisphere makes then run back into the camera housing.

Rather than take the camera down from its mast and open the camera body, it was decided to unscrew the polycarbonate hemisphere and drop into some earwig/woodlice killing powder, taking care not to get the powder on the fish-eye lens.

Whilst this seems to have resolved the problem (no earwigs seen in images over last 6-7 days, the powder was put in on a very damp day, and it begun to rain lightly before the hemispshere could be put back on. This led to the entrapment of high humidity air and possible some raindrop water in the hemisphere when it was closed, and led to an issue with very significant dew formation on the inside surface of the polycarbonate hemisphere. See AllSky Camera - Dew Problem, 2022-10-22.

2022-10-19

.Net Framework 4.8

AstroSuite Programs are being gradually migrated to Target .Net Framework 4.8. The programs migrated so far are:

AstroMain (2022-10-16, v3.56)
AstroLaunch (2022-10-16, v1.10)
AstroGuard (2022-10-17, v1.10)

Notes:

AstroObsCam.
An attempt was made to move AstroObsCam to 4.8 framework (2022-10-17, v1.10) but program crashed when trying to connect to Camera, so reverted to target .Net Framework 4. Same problem when trying to target .Net Framework 4.5. It is supposed that use of 'DirectShowLib-2005.dll' is preventing a successful migration. Getting runtime version from 'Reflection.Assembly.ReflectionOnlyLoadFrom("C:\More Programs\AstroObsCam\DirectShowLib-2005.dll").ImageRuntimeVersion' indicates that the Net Framework version for the .dll is "v2.0.50727".

AstroMain
The issue with AstroObsCam provides a warning for AstroMain 3.56 which uses various .com and .dll components and might run into issues when running a live session.
Although AstroMain was rebult after changing the target .net framework to 4.8, a query using Reflection.Assembly. returns Net Framework version of v4.0.30319
System.Data.SQLite.dll also returned a Net Framework version of v4.0.30319.

AstroPlan
AstroPlan / SqLite : examine : https://system.data.sqlite.org/index.html/doc/trunk/www/downloads-unsup.wiki

SBIG Driver Observations

Whilst testing operation of new facility that allows power to the SBIG Camera to be turned off / on my means of a REST API call to deCONZ some observations were made:

1) After switching off SBIG Camera Power whilst CCDSoft is connected to camera

1a) then attempting to take an image from CCDSoft Camera Control produces a CCDSoft Error Dialog
SBIG driver: Operating system error.
Error code = 1032

1b) A 'Connect Camera' from AstroMain seems to execute without a problem and implies that the Camera is connected when it is really unconnected.
CCDSoft likewise implies that the Camera is still connected

1c) If Camera is then disconnected from the CCDSoft Camera Setup, AstroMain think's that it is still connected. ObsMonitor's attempts to get Camera informature causes CCDSoft Camera setup to display 'Attempting Connnection' status message each time that camera information is queried.

1d) When Camera is disconnected in AstroMain, and then a fresh attempt is made to Connect Camera from AstroMain, it reports 'Connecting Camera Fail SBIG Driver: Device not found'

1e) When an attempt is made to take an image (3s snap) from AstroMain, an SBIG driver error is reported.
'Command failed. Error code = 206 (0xce)'

1f) When an attempt is made to Connect Camera from CCDSoft Camera Setup a CCDSoft Error Dialog is shown
   SBIG driver: Device not found
   Error code = 1027 (0x403).

   Same error dialog is shown when a fresh attempt is made to take an image from CCDSoft Camera Setup

2) After switching SBIG Camera Power back on

2a) 'Connect' operation from CCDSoft Camera Setup successfully works to connect with Camera

3) WIth SBIG Camera on and Connected

3a) 20s Snap frame started from AstroMain, and whilst exposure was being taken, 'RestartCCDSoft' was initiated:
AstroMain crashed with 'System.NullReferenceException: 'Object variable or With block variable not set.' at globals line 30931 in catch section of TakeImage() at code line Camera.AutoSaveOn = 1 . The catch section contains several references to the Camera object, and the Camera object has become set to Nothing, so the code line line produces the exception which is not longer caught and the exception bubbles up to the point that it causes the program to crash

2022-10-20

Casting Observatory Alarms to Google Home Speaker

I've previously created a prototype web app 'Observatory Alarms' ( http://www.astro-richweb.net/astro/session_alarm.htm ) for broadcasting alarms and alerts from the Observatory to a web browser (running on a Windows PC or IPAD), but found it impractical to use IPAD for running the web app at nightime, as the IPAD needs to be left running continuously and seemingly left with the web app on the browsers active tab.

In looking for a possible solution I began looking at some other means like a wifi based alarm or speaker system. A significant issues with using an alarm like an alarm siren is that they are typically much too loud and also the available sounds are limited. A speaker system would need to be WI-FI based and not bluetooth based, and the cost for such a speaker is quite high (all the cheap speaker systems are bluetooth based it seems).

It then occurred to me that by utilising an existing (but little used) Google Home speaker I could use it to automatically play alarms & alert sounds by casting the audio from by Observatory Alarms web app running in Chrome on the Observatory Computer. Casting from the Observatory Alarms web app to Google Home, would mean access to a completely customizable range of suitable alarm/alert sounds, with a volume much more suited for nighttime / bedroom. Other benefits from the Casting method is that the existing system for sending events, alerts and alarms from the Observatory would be essentially unchanged, and there would be no new outlay for a network connected alarm or speaker.

Development Computer Test
Initial test using Chrome on the Development Computer showed this Casting method is feasible. Volume control on the Computer can be on mute (or zero volume) and the audio still plays on the Google Home speaker.

Observatory Computer Test
Google Chrome was then downloaded and installed on the Observatory Computer. Then Opened 'Observatory Alarms' web app in Chrome, cast the page to Google Home speaker, and began a test alarm. The alarm audio was successfully cast to the speaker in the house.

Actions
- Install chrome onto Observatory Computer
- Set 'session_alarm.htm' as the home (start) page on Chrome browser and set Cast button to Always Show
- Add checkbox option to launch Google Chrome from AstroLaunch
- Install 64-bit version of chrome onto Development Computer instead of the existing 32-bit version.
- Make 'session_alarm' chromecast enabled
     (look at https://stackoverflow.com/questions/44999267/how-to-chromecast-enable-a-website
     and at https://developers.google.com/cast/docs/overview )
    This seems difficult to do and requires registration, a fee?, https: Attempt to use basic method didn't seem to work and broke the webapp so removed again
    Workaround is to Cast and then right-click on Cast Button and enable the Always Show Icon button.
   And then remember to manually click Cast button after Chrome starts up

- Create a clever means to quickly accept an alarm once woken in order to turn off an alarm sound
- If the method is successful consider the purchase of a Nest Mini (£49) or a Lenova Smart Clock Essential with Google Assistent (£40)
- Create a backdoor means to enable AstroGuard to post an alarm for the Web App if AstroMain stops responding.

Accepting Alarm Options
- Open IPAD, Open VNC Connection to Observatory Computer, Click on Accept/Snooze.
- Lower Audio on Google Speaker / Go to Silent and wait for Alarm to timeout.
- Employ a Zigbee Switch to communicate to the Observatory Computer to send an "accept" notification to the web site that is then read by the web app which acts upon the notification and accepts the alarm (which stops the audio sound coming to the speaker).

Tests
Tests show that my solution works.

- For implementation the alarm/alert sounds coming from the speaker needs to be loud enough to wake me, but not loud enough or long enough to wake /disturb my wife as that will lose me any and all spousal approval points. The volume of Google Home speaker (which would be positioned closer to me) is adjustable so can I set it with low volume to start with and see how it goes.

The Web App has snooze and accept buttons to turn off or defer the alarm sound, and I whilst I can open my IPad and open a vnc connection go to Chrome and read the alarm/alert message and accept it. I could look at look into using a zigbee switch beside by bed that can get a accept/snooze trigger back to my AstroMain program on the Observatory Computer and from there get a notification to the web app to stop playing the alert audio. Meanwhile I could open IPad and open web app from there to read the alert/alarm message and decide what to do.

I was worried that the instigation of a Hey Google conversation or the activation of an alarm set separately in Google Home /on through Google assistant might turn off the Cast from my WebApp but this doesn’t seem to be a problem in the tests I’ve carried out.

- Saying ‘Hey/Ok Google, stop cast’ stops the Observatory Alarms cast.
(but I have to go back on to Observatory Computer / Chrome and click Cast button again)
- Saying ‘Hey Google, play last cast’ gets the response ‘Alright check out this Music station on YouTube Music’
- Saying ‘Hey Google, pause cast’ does nothing
- Saying ‘Hey Google, start cast’ gets the response ‘Sorry, power control is not supported yet’
- Saying ‘Hey Google, play cast’ gets the response ‘Playing some music on spotify’

- Saying 'Hey Google, silent' suspends the cast
- Saying 'Hey Google, continue' resumes the cast
- Saying 'Hey Google, resume' resumes the cast

Best Option
- Touching the top of Google Home speaker and then saying "Silent" suspends the cost
- Touching the top of Google Home speaker and then saying "Continue" or "Resume" resumes the cost

2022-10-21

Observatory Zigbee Network

A Zigbee Network (AstroGW) is now successfully operating in the Observatory which allows remote and automated access to Smart Plugs controlling on/off operation of the Pulsar Dome, SBIG Camera, Dehumidifier and an Auxillary Light with monitoring of the open/close status of the Observatory Door and the Dome's Shutter.

The network as of 2022-10-22 is illustrated in the following chart (created in deCONZ)

The network is coordinated by a Combee 2 USB Stick (https://phoscon.de/en/conbee2)
Devices were added to the network and setup using the Phoscon App (https://phoscon.de/en/app/doc)
Visualisation of the network and information its various nodes and operation is using the deCONZ program (https://phoscon.de/en/conbee2/software#deconz)

The deCONZ program allows gateway access to on/off and open/close states of the various devices and permits the changing of the on/off state of lights and smart plugs using REST APIs https://dresden-elektronik.github.io/deconz-rest-doc/

The Network was later extended to include AllSky Dew Heater on 2022-11-14 & Portable Remote Control on 2022-11-18.
(The 'end-device' labelled 0x7CED is a Nedis 4 button remote (keyfob) but it hasn't been possible to incorporate it into deCONZ's REST-API )

Zigbee-AstroMain Integration

Pictures illustrating current level of integration :

Device Control

Controls were later extended to include control for AllSky Dew Heater on 2022-11-14 :

Observatory Status Picture

Conbee II - Firmware Reinstall (2022-10-22)

Issue : Firmware on Conbee II USB stick were accidently corrupted through an attempt to running newly installed ZShark software (2022-10-22).

Description
ZShark (win/zshark_V1_0501.exe) was installed on the Observatory Computer with the aim of eventually using it to sniff out the button event numbers associated with a future 4 button smart remote controller. After innitial attempt to run the ZSHark program failed (itw would find the Conbee II device). It was thought thise might be because deCONZ was running so after closing deConz a second attempt was made. ZShark indicated that the device on COM7 occupied by the Conbee 2 USB Stick) was missing firmware and asked to proceed to install firmware. With no more than a slight though that this was probably something zShark needed to add, 'OK' was clicked and something was presumably installed on the Conbee II.

This proved to be a major mistake, whilst ZShark appear to then connect and at least 2 packages were passed, I was left unsure what I needed to do next and resigned myself that I would need to look at setup / running of zshark in more detail and closed the program. deCONZ was restarted but it fail to connect to the Conbee 2 device.

Multiple attempts were tried to connect. Including removal and reinserting of the USB stick. With deCONZ is running but apparently not conneced to the Conbee II device, REST API (Get) calls seem to superficially work (they return values from when the Conbee II was last working) but REST API (Put) give an httpResponse containing an error of type 901 (Intenal error 951).

So it seems that the firmware on the Conbee 2 has become corrupted and prevents the use of the Observatory's Zigbee Network until the necessary firmware is reinstalled on the Conbee II. It is likely that the network devices (Smart Plugs and Open/Close Sensors) will have to be potentiallly all reset and re-attached to the network. It is unclear if back-up made earlier in Phoscon will allow the process to be shortened the process.

Firmware Reinstall
The method used to reinstall firmware is based on that presented at https://flemmingss.com/how-to-update-conbee-conbee-ii-firmware-in-windows-10/

Have neccesary firmware is deCONZ/firmware folder ("C:\More Programs\deCONZ\firmware). This comprised
- deCONZ_Rpi_0x26400500.bin.GCF
- deCONZ_ConBeeII_0x26780700.bin.GCF
(Latest firmware at http://deconz.dresden-elektronik.de/deconz-firmware/ )
Open Windows Command Prompt (CMD) and change working directory to the deCONZ/bin folder
cd "C:\More Programs\deCONZ\bin"
Run the following command to check the COM-port number for the USB interface (Listed under “Path”):
GCFFlasher -l

This produced the following table:
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------+--------+---------+------------+-------
\\.\COM4 | 0x0403 | 0x6015 | PA2U9D23A | ConBee
\\.\COM6 | 0x0403 | 0x6015 | US2RETFYA | ConBee
\\.\COM3 | 0x0403 | 0x6015 | DN033EKNA | ConBee
\\.\COM5 | 0x0403 | 0x6001 | AK08TPBAA | Generic FTDI
\\.\COM7 | 0x1CF1 | 0x0030 | DE2456287 | ConBee II
COM7 is the known port number for the ConBee II device. Its unclear why ConBee was seemingly detected on Ports COM3, COM4 & COM 6. They have completely different equipment attached, but is does explain why deCONZ was unexpectedly including 3 ConBee devices in its device list

V3_17 indicates that GCFFlasher is the latest version according to the deconz.dresden-elektronik.de/deconz-firmware directory
Flash the ConBee II with the required firmware using the following command. GCFFlasher -d COMX -f Y
(Replace X with COM number and Y with firmware filename)

Firstly I attempted to flash the 'Rpi' file

GCFFlasher -d COM7 -f ..\firmware\deCONZ_Rpi_0x26400500.bin.GCF

This gave an error when writing the image

GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device COM7 (ConBee II)
deCONZ firmware version 31000700
R21B18 Bootloader
Vers: 2.07
build: Jun 17 2019
flashing 127650 bytes: |=
dev: ERROR writing image (15 ms)
I tried several times with this command and even re-aquired the firmware file from the deCONZ site
But it produced the same error each time
Even though the first step failed, I opted to go on to the second step and flash the 'ConbeeII' file

GCFFlasher -d COM7 -f ..\firmware\deCONZ_ConBeeII_0x26780700.bin.GCF

This appears to succeed ok

GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device COM7 (ConBee II)
R21B18 Bootloader
Vers: 2.07
build: Jun 17 2019
unlock! (101 ms)
flashing 163230 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts
I opened deCONZ and it successfully connected to my ConBee II device, and surprisingly, but thankfully my Zigbee network was still there, through 2 nodes (Observatry Door and Pulsar Dome, which were for devices which I added to the network after the last time I created a backup in Phoscon) didn’t initially show connection lines back to the other nodes or the coordinator. After several minutes one of these (Observatory Door open/close sensor) did re-attach to the network, but the other didn't re-attach (REST AI confirms that it is unreachable).

Thinking that I may have to reset device and re-add it in Phoscon), I proceeded with a Reset Node in deCONZ and delete Light in Phoscon.
On going to the Observatory it was realised that the Smart Plug for Pulsar Dome wasn't inserted into a power socket (it had been removed earlier in day due to a connection issue with the Dome) and this is why it couldn't be connected to.

Added the 'Pulsar Dome' as a new light and it rejoined the network Ok (this time as light/6)
Anyway I’m taking the experience as a lesson and I’m not going back to use ZShark any time soon, if ever.

This Web Page:	Notes - Session 1047 (2022-10-14)
Last Updated :	2024-03-27
Site Owner :	David Richards
Home Page :	David's Astronomy Web Site

David's Astronomy Pages Notes - Session 1047 (2022-10-14)

Session Aims & Highlights (2022-10-14)

Operational Issues (2022-10-14, S1047)

Conbee II - Firmware Reinstall (2022-10-22)

David's Astronomy Pages
Notes - Session 1047 (2022-10-14)